As a web designer at Four Kitchens, part of my job is leading the production team’s visual design objectives. A key part of this process is ensuring the client’s satisfaction with the overall look and feel of the site. Since most of my projects utilize an agile development process, I am no stranger to shifting objectives or newly added requirements. One of the biggest challenges I face in agile development is adapting the design process to fit.

If you’ve ever worked on a traditional web design project, it should come as no surprise that the most common way to get client sign-off on visual design is through comps. Generally speaking, a comp is a comprehensive, high fidelity, Photoshopped layout of a website—or rather, what appears to be a website. It is just an image after all, an image of what your website would look like under perfect weather conditions. This delusion of grandeur, when used as a deliverable or finished product, often misleads the client into a false sense of usability. Here are my issues with comps:

1. Looks Like in Photoshop ≠ Looks Like in Browser

This is not new information: different browsers render web fonts differently—colors can vary, not to mention the plethora of possible sizes of a user’s screen on any given device. Still, it is important to understand how delivering a comp as an end product sets up client expectations. Even the most tech-savvy clients signing-off on a comp will, by nature, expect to see that perfect image and no deviations. Don’t get me wrong; it’s not their fault. As production teams who have delivered comps for years, we have set them up for that exact expectation.

2. Images Don't React

Comps do not present the client with any sense of interaction. Sure, as a designer you can present the various button states as separate images to a client, but you're asking them to “imagine” how the button would function. Should you also expect that they imagine the multiple methods of interaction for mouse versus touch devices? Not to mention, you are creating more work in an outside application that will have to be re-created in code, bringing me to my next point.

3. Costly and Finite

As a designer, you spend many hours focusing on detail after detail of something that will never see the light of day after the project is over. And if the scope changes or new functionality emerges, which is inevitable working for an agile shop, your perfect comp gets thrown in the trash. Or worse. You have to redo the comps. Sigh.

4. Less Team Collaboration

Working on perfecting comps means that most planning decisions are made between the designer and client. This exclusivity leaves other team members out of the process, and is a perfect recipe for unhappy developers. Developers get stuck trying to create an interaction thought up by the designer and client, who may have a limited understanding of how it’s actually going to be implemented.

Changing the Process

So, with all these problems attributed to comps, how can you transform this archaic design process? Let me share how my team and I adopted the design-in-the-browser process for a recent client.

My initial reaction to the idea was something along the lines of: “YES! Let’s design in the browser! Get rid of these over-detailed, time-sucking, lies!”

My excitement quickly turned to panic when I considered the giant hole this would leave in my design process. Now I needed to come up with a way to sell a visual language for a website—an extension of a well-known brand—and get my client to buy into it without my trusty old comps. Quite a challenge, but solving problems is what I do …

Style Tiles for Miles

Long before my team and I began designing in the browser, we’d used Style Tiles to assist clients in making decisions on a sites’ aesthetics. If you don’t know about Style Tiles, you need to! They are awesome because they allow designers to create fast iterations of very broad visual elements (typography, color palette, etc.). We employed this strategy to achieve faster sign-off on comps, often resulting in fewer iterations and a clearer understanding of the design objectives.

Style Tiles had helped to get comps approved, could they also work if I got rid of comps? The answer, as I soon came to find out: absolutely! However, Style Tiles, in all their glorious splendor, only offer a vague picture of a site (which is the point). Using them to begin building an entire site in the browser would be a very daunting task, especially if more than one designer/developer is helping build the front-end. It was easy to imagine the blank look on my colleague's face if I sent him an approved Style Tile and said, “Here is the design. Make it work!”

Enter the Style Guide

Creating a website style guide is not a new concept. Just look to the team at Starbucks and stare in awe at their thoroughly documented guide. It comes complete with multiple layouts, menus, and widgets—well done for a coffee shop. A website style guide doesn’t have to be this fancy or complex; at its core it simply shows the user interface elements used on a website. For my project, I started my Style Guide using Photoshop. Yes, that is correct. I still use Photoshop, along with paper sketches, mood boards, whiteboards, etc. The point here is that I don’t ship these off as a deliverable.

After playing in my Photoshop sandbox, I began building the basics in code, starting with the client approved visual design elements from my Style Tile exercise, and then moved onto more fully fleshed out sections: a header with fully responsive navigation, sidebars with multiple backgrounds, complete footer, etc. Being careful not to get too far ahead of myself, I built just enough to cover the web page elements needed for the first few sections we’d be building.

I feel it is important to note that I did not use the style guide for client sign-off, rather to document the look of the site. Client sign-off happened on the real features as we completed building them, allowing the client to authentically interact with the site.

After sufficient wireframing and more play in my Photoshop sandbox, I became more comfortable designing the site in the browser. I was able to make design decisions immediately in code. Because many elements we’re already defined thanks to my style guide, it was so much faster. And the best part is, once the team (client included) was satisfied with a design, it was done. It’s already been styled with real CSS and it’s fully responsive. My client was thrilled to be able to share it with users right out of the starting gate. I could start collecting user feedback, running tests, iterating pitfalls, and producing an overall better user experience.

To sum it up, the design in the browser improved UX in the following ways:

No False Expectations

Internally and externally, our teams were able to test the site’s UI design on any browser, on any device. Clients didn’t have any expectations of how the site would hypothetically look during an interaction, because it was already working.

Design, Build, and Test Faster

Doing the design directly in code allowed me, as a designer, to test the interactions immediately. This tightened the production cycle (design > development > test) and I could instantly make iterations on a single piece of functionality, changing it site-wide if necessary.

Full Documentation

By starting with a style guide, our team had fully up-to-date documentation of the site’s design aesthetics at every step in its production. This document served to maintain control over the design and ensure brand consistency. It also makes an excellent training aid for new members of the team.

Realign the Design

This process allowed the design of the site to grow organically and we were able to realign the design with every new addition. It was perfect for an agile shop, allowing me to design for new features, not force new features into an existing design.

Full Team Collaboration

The icing on the cake: this process brought everyone into an equal understanding of the site. Rather than trying to predict interaction pitfalls, we were course-correcting and changing the functionality and design as a unified team.

In Summary

Comps are part of an old design process, so stop catering to your client with inauthentic, hypothetical experiences. Present your work in the browser to give everyone the real experience.


Image of figs courtesy Shutterstock


Nice article. I think Stile Tiles are wonderful and, in fact made a tool to make it even easier to get start on your colors and typography ... it starts with a page very similar to a stile tile and is optimized for Zurb Foundation - but it'll work with any CSS, Sass, LESS set up too:

And here's a demo:

I've been designing in browser for the last couple of months. You're right there's some many advantages to getting started with browser design. But I find that you have to change your process significantly when working in the browser. So significantly that it changed me as a designer. After thinking about the last few months, I wrote up some tips that could help others get started, hopefully.

Yeah, I liked your short article Andrew ... picked up a hot tip with the Noun project thing...invaluable! I do think that, as with all things, there's no one cookie cutter way to do this. I think we'll look back at these PS vs in browser arguments and think it was all a bit silly. It's not black and white and there's room for variation in personal workflow. Do you already have a team assembled? Are you a one man shop? Do you have PS or Illustrator skills at all? Or, do you have any coding skills?

Obviously, mobile and tablet and other form factors are increasing in market share so we have to implement something like RWD/mobile first to get the job done. This sort of forces at least more in browser prototyping no doubt. But, being a dev first guy, I will always appreciate an extremely talented designer, and well, they love tools like PS. So while I'm more or less pro design in browser I think as always "it depends".

Interesting article Jared, thanks! While I worked as a front-end engineer, I had a lot of discussions with our designers on these topics. I didn't understand why designers create non-reusable specs in PDFs or Wikis, while not thinking about the users of the styleguide, the developers. I think we should let developers extract colors, fonts, assets or grids from the designer specs. This is when styleguides really become usable. They need to be always up-to-date and easy to access, as well as highly structured. This was enough motivation for me to build a company especially focusing on a solution for these problems.

I disagree with that but I can see the author's point. I would call the article 'Building a *Better Visual Design* by Designing in the Browser' instead. User Experience is something wider than placing elements in the interface. The process mentioned here is UI and Visual Design, which are the latest steps in the process. User Experience is about user analysis, requirements, IA, mockups and of course also UI and visual. If the browser design happens after them, I can see the benefit of skipping the photoshop step.
Agile often sacrifice the pure UX for the benefit of the final product (which often is a Minimum Viable Product).

I've been skeptical about how designing in the browser could improve my designs, but there are some good arguments here. I can see now that it would improve how my clients or even project managers experience the design. The downside is it seems to require a strong knowledge of front-end skills.

I would buy this argument if you actually mentioned something - anything - about how this makes the resulting UX better for _users_. As it is, your rationale is all about your own process and that of your team. That's nice, but has nothing to do with the title of your article.

this is really awesome i must say. you have covered almost everything what actually need to know. but all those tutorial need some visual experience so if possible give us some of that.

We are taking a “partnering” approach and collaborating with similar companies and freelancers to offer end-to-end programming projects. You can partner with us to deliver our dev projects ! We are always networking !

I agree, the Page Description Diagram is certainly a helpful exercise. I also think wireframes and prototyping can be useful to identify interaction patterns before the building begins. Whatever your direction, the interaction design process can occur at the same time as the visual design. The style guide is the marriage of the interaction design patterns you've deemed necessary and the visual design.

Unfortunately I do not have a public style guide available. Here is a great write-up by Steve Fisher that gives some nice examples:

Interesting article Jared. How do you see the interaction design process that precedes design and the use of style tiles? I think something like the Page Description Diagram could be incredibly useful over a traditional 'wireframe.'

Great article! It would be great to see an example of a style guide you made if possible.