Designing in Browser:
A Real Workflow
In my last article, “The When, Why and How of Designing in Browser”, I described some reasons why someone would or would not begin a project in browser, some high-level tips on process and workflow, and a brief real-world scenario where designing in browser was the first step.
I want to dive a little deeper on some real-world design-in-browser instances. I’m designing in browser with my team on a current philosophie project — but there’s a twist: a mobile web application meant to have the look, feel, and behavior of a native iOS application.
It took us some time to figure out the best workflow for this project, but in the end, we chose to go with a happy medium of some traditional design exploration and Adobe Photoshop work mixed with in-browser iteration.
Here’s how it went:
The Kickoff
To begin, the client is, in most senses of the word, a startup. They have backing from a larger company, but their product is an independent standout from the larger company’s offerings. Their team consists of a product owner and a couple of potential users on the admin side; our team consists of a UI designer/front-end developer (me!), two software engineers, and a part time UX designer and a product manager.
The goal of the kickoff, as with almost every kickoff, was to get everybody involved on the same page.
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.
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.
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.
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.
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.
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.
