We established a set of preliminary personas and use cases for the app. We revisited any existing brand assets and wireframes and conducted a design studio dissecting and breaking down the information architecture. We briefly discussed what our MVP deliverable would be: a web app that would have as much of an iOS look and feel as possible without sacrificing speed.

We departed from the kickoff with a clear idea of our marching orders: re-architect the app based on our design studio, provide a light branding kit based on, but not directly related to, the parent company, and, of course, build and deploy the app.

The Stuff that Came Before In-Browser

In this project, it took a little while to conclude that in-browser was a logical and viable option for us.

To start, I spent a few days examining the core features of the app and rebuilding the information architecture and user flow. We needed a solid foundation, some dedicated design time before we could actually build anything.

High level UI sketches that eventually became a set of digital wireframes.

After a few days and many discussions, we emerged with a logical set of wireframes for the whole app.

At the same time, I quickly put together a mood board.

The goal was to leverage the parent company styles but create a friendlier and performant look and feel.

On the engineering side, the developers started testing API calls and performing preliminary setup that any app could have.

The Decision to go In-Browser

The “curveball” of the app — having it look and perform like and iOS app without actually being an iOS app — warranted a fair amount of research.

Originally, we wanted to go with the safe option, at least for us, and build a Rails app with modified Bootstrap styles. I would have modified the styles and attempted to build some custom transitions that called back somewhat to an iOS look and feel.

However, we discovered a front-end framework that could suit our needs: Ionic. Ionic is a front-end framework with out-of-the-box support for Angular.js, meant to simulate the look and feel of an iOS app. We had a lot of reservations about it out the gate: none of the engineers had a lot of Angular experience and we didn’t know what kind of bugs we might come across or if the features really suited our needs.

Luckily, one of our engineers dedicated a night to just mess around with Ionic, and the next morning, he presented his findings. And it was awesome. We decided to throw caution to the wind and jump right in with the Ionic front-end.

We used separate Github repositories for the Rails back-end (left) and the Angular front-end (right).

This is how it would work:

Ionic lets you write markup that generates a view that simulates an iOS look and feel. I would help write HTML and CSS static pages within the Angular app. The Angular engineer would support me with creating new templates and interactions using Ionic and wire up the front-end and back-end. Another engineer would build the back-end in Rails. Dream team material.

Photoshop ←→ Browser

Having determined a high-level workflow, I decided the best course of action was to conceive a couple of designs first in Photoshop, to organize my thoughts from the gate. I spent 3–4 days working on these comps, using Invision to perform rolling design reviews.

We used Invision as the initial platform to getting rolling feedback on designs.

Once approved, I used these comps and the wireframes to build out the static pages.

We used Pivotal Tracker to keep my front-end stories and the engineers’ back-end stories separate. It didn’t really matter who did what first: if the engineer completed the back-end component of a story, he would spit out an unstyled view, and I could go in and style it. And we would both mark our stories as “Delivered”. Same the other way around: if I ran ahead and built out a static page, the back-end developer would pick it up and wire it up. We wouldn’t deliver our stories until the wiring was complete.

Using Pivotal Tracker: one story with corresponding front and back-end components.

Iterative Design Improvement and Switching Between Traditional and In-Browser

It was midway through my time on the project, and things were going swimmingly. We had been having ongoing discussions about our brand voice, that, while I hadn’t ignored, I also hadn’t spent too much time considering up until that point. As I was establishing the look and feel more and more in the code, we decided we needed to improve one aspect of the brand for the MVP: a “Guide” of sorts that would lead the user through onboarding and other main features of the app.

The Guide at this point was not much more than a rudimentary placeholder in the app. So, in order to give the Guide the design love it needed, I extracted myself from the code for a day or two and worked solely in Adobe Illustrator to develop this character.

In the end, the Guide had a certain facial expression and manner of speaking. I also introduced some new colors to the guide’s clothing and face.

Once we got on the same page for the Guide, it was really easy to jump back into browser and apply some modified colors and styles. And it was really easy to insert the Guide into the app: I exported the Illustrator file as an SVG and just stuck them in place of the colored dot. Insta-lean-branding!

It’s an Ongoing Process

It’s week four for me on this project and, unfortunately, my design time is wrapping up. Now that we’ve established a solid architecture, look and feel, and brand character, I’m working as fast as possible to get the front-end styles up for the rest of the app. Of course, we still don’t have everything figured out. We still have some big questions about core functionality. But we’ve been doing it in a lean and collaborative way, and that for me is a big win so far.

The Takeaway

Have a clear understanding of your various roles. Continuously and constantly involve the client. Gain an understanding of your dev environment and be aware of any potential bugs or issues. Pivotal Tracker is your friend. It’s okay to use Photoshop to set the visual and conceptual stage.