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.