The When, Why and How of Designing in Browser

If you’re a designer in the tech industry, you’ve probably been exposed to or read articles about a hot topic in design today: designing in browser. The concept is as simple as it sounds. Rather than spending hours, days, weeks and months designing those pixel-perfect comps in Photoshop, a mainstay in a waterfall-oriented development process, designing in browser allows you to take whatever sketches and preliminary work you’ve conducted and enables you to jump right into the text editor and emerge with shippable code.

But how do you design in browser effectively?
How do you know when the project calls for it?

Let me walk you through when, why and how you might decide to design in browser vs. doing it a more traditional way. Which, for the sake of this article, will be designing in Photoshop.

To start, my version of “designing in browser” is less “designing” and more “hacking in browser to get what you want”. To me, design is solving a problem for your users. The “in browser” is just another tool in your arsenal, the fastest way to ship clean code that has a considered design via a series of collaborative meetings and sketching.

When do you design in browser?

There are many articles in the tech community that sing the praises of designing in browser — it’s future of web design, we should Kill Photoshop — to name a couple. I agree that while designing in browser can be your go-to when kicking off a design project, there will be times when factors — client needs, nature of deliverable, time constraints, for instance — don’t allow you to work that way. Here are some potential scenarios where you wouldn’t:

The client’s needs aren’t suited for designing in browser. You may tell yourself, “well, just don’t work with them!” But we all know this can’t always be the case. Maybe the client’s priority at the time is to present a highly polished website to stand out from their competitors or to get more capital from their investors. Perhaps their feature backlog is ever-changing, or they have many fundamental issues with their vision. In this case, traditional wireframing, then comping, may be the most efficient way to prototype their needs for their users.

Many clients see visuals as results. Sometimes it’s more effective to deliver 10–20 high fidelity comps in one week as opposed to 1–5 working, but uninspiring, pages.

The system and layouts of the website in question are too complex to visualize and code at the same time. We’re human. Most of us have limited brain capacity to think in two spheres. Whereas some may tell you that coding and designing go hand in hand, it’s really tough for me to envision a complex layout with many moving parts while writing divs for it at the same time. Studies show that we suck at multitasking, and designing in browser often feels that way. Granted, time and experience will definitely make you better at visualizing faster and writing cleaner code. So keep at it.

<p class=”em”>This sometimes happens. Like, whaaaaaa?</p>

You’re in the “refinement” stage of design. Let’s say you’re past the point of MVP with your project. You have a working website with a decent layout, and you’re ready to add more features. If your users have expressed pain points over certain design decisions you made in browser, like maybe that call to action wasn’t clear enough, or they don’t know what to read first on the page, it could be an opportunity to jump back into Photoshop and revisit those pain points in a thoughtful, refined way.

To me, the biggest challenge of designing in browser can be summed up by Andy Budd:

“As the best design tools are the ones that put the smallest barrier between the creator and their creation (the pencil is a good example of this) designing in the browser adds an unnecessary level of cruft to the process.”

— Andy Budd

To add onto that: You actually enjoy the process and craft of pushing those pixels around on the artboard. Many web designers come from formal graphic design backgrounds. Taking it slow and scrutinizing over every detail is in our blood.

The reasons why we design in browser vary greatly, and the approach we take highly depends on the task that is called upon us. That being said, when the situation does call for designing in browser, here’s my take on it.

How do you begin designing in browser?

There are so many ways to begin a project. Let’s say for this article, I use the way philosophie typically begins a project with the product owner(s) of a newly incorporated, newly funded startup: a kickoff. Many thought leaders in design, Dan Mall for one, detail ways to facilitate a successful kickoff, so I won’t go into the details here.

During our kickoff, let’s say we’ve determined a set of users and their pain points for our product, a brand statement defining the what, why and how, a hypothesis statement that we intend to solve with our first sprint, perhaps even rudimentary wireframes or a feature list. At this point, we’ve gained a vague understanding of who we’re designing for and what the client wants to convey to them.

I like to start off with moodboards. They help to paint the picture of the brand expression without wasting too much of my time and effort. For this, I tend to trawl Pinterest, Dribbble, whatever designer fodder I can find to curate visual options for the client.

From here, I pick a framework, the skeleton for which to quickly markup the layout and paste in the UI. For marketing or consumer-facing sites, I tend to prefer Foundation because the options are presented to you in the code. They’re more rudimentary, in my opinion, and easier to override than Bootstrap. Bootstrap is a robust framework ideal for admin-facing applications. There’s less work out of the gate with Bootstrap, but more options to painstakingly overwrite in the CSS.

Next, the style guide. Beginning with a style guide, or a series of “style tiles” is pretty important to keep your design elements organized and succinct within a design system. I won’t go into the importance of style guides because the reasons have been well-explained by others, but I will say that a style guide is the easiest way to make sweeping design changes as they come down the pipeline. And that’s one of the biggest reasons we design in browser in the first place. I’m accustomed to building style guide UI elements manually on an as-needed basis, but you can use KSS methodology, or even a gem like Hologram to help you automate the generation.

Finally, the composition. Something I try to keep in mind: don’t lose sight of your design principles. Eye movement, hierarchy, contrast — it’s easy to get lost in code. When I used to exclusively design in Photoshop, it enabled me to think more conceptually and granularly about the design: I could experiment more with new ways to call to action, a new layout, a compelling animation. Designing in browser fundamentally prevents you from thinking outside the box in that regard. The easiest way for me to do it is to go from lowest fidelity to highest. That means, plain text, then html markup, then add framework layout, then add selectors, then style selectors in CSS.

Using browser tools

So you’ve gone and created the first iteration of your site in browser, and it’s time to review with the client. This is where the magic happens. Rather than the typical unending back-and-forth design loop, you can potentially take care of most to all design feedback in one meeting. Here’s how I use the inspector in Chrome:

Client wants to make a copy change. Open the inspector and “edit text”. Screenshot the change.

We decide to add a new content column in a section on the page. Open inspector, “edit HTML”, copy and paste column. Boom, new column. Screenshot the change.

We need to increase the size of a radio button, tucked inside a form. Click magnifying glass, right click the button. The magnifying glass hones in on an element nested inside a parent. Make the changes in the styles. Screenshot.

We need to change the color of something, make something bigger, anything related to style. Edit styles, screenshot screenshot screenshot.

Note that I prefer taking screenshots over using Chrome tools to save the code. This is because using the inspector is not the way to generate the most beautiful, semantic code; it’s just a cheat to experiment with a design decision or get approval from a client. Using screenshots, however, lets you preserve the change and figure out the best way to integrate that with your code base later.

Working in teams

Disclaimer: philosophie uses Pivotal Tracker as the project management tool of choice, and usually Ruby on Rails as our go-to stack.

Rather than a typical waterfall-oriented design process I described in the beginning of this story, designing in browser allows you to work in sprints with the rest of your team. The first sprint may consist of chiefly foundation or bootstrap styles. This is merely the MVP design. From there, the second sprint can slowly work on the branding, revisit typefaces, improving hierarchy, and other improvements you and your team have decided. You can even enter the refinement period here and use Photoshop, which I mentioned earlier.

As for how we integrate design stories into Pivotal Tracker, I’ve found that it’s been effective to create user stories for front-end tasks, separate from back-end stories. This way, you can let design run ahead of development, or let the engineer create models and controllers first, leaving you to style the view. It’s interchangeable.

For instance: while you as the front-end dev can create and style the static pages such as the homepage, a contact form, or text page, the back-end dev generates inputs and views for the login. Then, the front-ender can jump on the login pages and style them.

How has this worked in the “real world”?

On a recent client project, we determined that designing in browser was the best way to keep within budget but still deliver a fresh, clean look. I quickly mocked up layouts and pages in using Bootstrap as my framework and Sublime Text as my text editor, making low-hanging-fruit improvements where relevant. I also worked in tandem with developers as I mentioned in the previous section, taking on front-end stories and bugs while they worked on the back-end.

Midway through the process, the client wanted to explore new home page directions. Not wanting to limit myself on design, I decided that Photoshop was the best way to execute several well-composed iterations of the home page. It was relatively painless to go through a couple of rounds of feedback on just one page.

With these new styles composed in Photoshop, and with my UI elements in place, I merely had to change the styles in one place, and the whole site conformed to the new homepage design.

Concluding thoughts

There is no end-all-be-all to designing for the web. Just because you mostly design in browser doesn’t mean you should give up Photoshop.

For me, the most valuable aspect of designing in browser is to curtail the pain that comes with traditional design process and to work with your team in the leanest way possible without having to sacrifice of your own design principles.