iterations

j. nicole mors

Down with the King

Death of the Design Comp

I originally gave this talk during Design Week, when preparing for that talk with my coworkers and design friends, I felt like these topics and the idea of changing ingrained design processes can get a little heated… I am not trying to be dogmatic, these are my observations being on the ground and trying to work in our current web landscape.

Many of these ideas aren't even mine, smart people have been talking about some of this stuff for awhile now. I want to open the dialog and see if there can't just be a better way. Here is a quick history of the comp and an overview of how we use comps today in our work flow. I am going to share some alternate tools and processes to the comp.

A design comp (short for comprehensive) historically in print terms was a sample that the printer would print out to get a signature on. It was proof, for the printer to get sign off on saying that everything was correct before moving into print production.

This insured that the person signing off knows exactly how all of the elements on the page were going to come out on the final print. This would be the same for 100 prints or 10,000 prints.

Because we (designers of the web variety) had no other point of reference, when we needed an approval process, we carried this same process over and applied this concept of the “proof” to the web.

Get Complicated

Get Mobile

Most people approach mobile like this. Phone, tablet and desktop. We use techniques such as breakpoints and optimize our designs for these sizes.

So what does that mean for pixel pushing? Well lets do the math. Pre-mobile, you did a comp for each page. When comping out for different size viewports you create comps for each page along with a comp for each viewport. So lets say you start mobile first, each comp takes you 10 hours, then you do one for tablet, and desktop, and this you would do for each page you would like to get “sign off” for from the client.

Who knows what the future holds, you can see where this process is no longer sustainable, even our current phone, tablet, desktop is stretch, but if you start expounding that out, you get the point. You can see where that adds up. It is time consuming. It is unsustainable.

After all those hours and hours of pixel pushing what do we have after all of our efforts, we have a nice picture of a digital thing. A flat picture, lacking all interaction and experience.

A nice picture

of a digital thing

A picture is worth 1,000 words, but what about 1,000 interactions?

Instead of hanging this picture on a wall where it belongs, we use this comp, or picture towards two main goals.

  1. Communication with Clients and Stakeholders

    It gives us a way to help clients visualize the final product. It also gives us a milestone or sign off similar to print, the BIG difference is at this point our comp isn't going to print production, we aren't printing this picture. It's going into development, which is our second goal of the comp.

  2. Design Specs for Developers

    The comp provides documentation of specs for design. At best, the comp is meant to be a road map for developers, and I say at best because developers usually get it wrong.

But it's not their fault.

Not trying to say all designers are control freaks but, the comp gives us this sense of illusionary control because use rely on this picture. I have heard on more than a few occasions, even the best designer use the words “pixel perfection”.

The comp gives us as designers a false sense of control where there is none.

The truth is, unlike print, the comp is never an exact representation of how the design will be rendered in the browser. Period. And that design will be rendered differently in every browser.

Comp = comprehensive = lie.

It's not comprehensive at all. It lacks all interaction. It's flat, it's a picture of website.

People love analogies, so here is one, just to illustrate our dilemma. It's a story about a different kind of king… an Emperor. So just a refresher if it's been a while… the story goes like this:

There is a vain Emperor and all he cares about is wearing the freshest clothes, so he hires these two guys to make him the best, most magnificent clothes. There's a problem tho, these dudes are swindlers. And they promise the emperor they can make him an awesome outfit out of a special fabric. However this special fabric is invisible if you happen to be hopelessly stupid or unfit for your position. The Emperor, says to himself, well I am not stupid or unfit, nor do I have anyone like that working for me, ya know what, lets do it. So the swindlers get started and just to be safe the Emperor sends his top guys to check on his clothes… he sends his Ministers. They unfortunately do not see the fabric, but for fear of seeming unfit, they lie to the king. When the Emperor's new clothes are finished he Marches in procession before his subjects. EVERYONE pretends to see his clothes, no one says a word. Except. One little kid. This kid calls the Emperor out, “he has no clothes on”. “The Emperor, is naked. He doesn't care about looking stupid and he has no fear of look incompetent. He is just calling it like he sees it.

Let's swap out some of the characters and apply this story directly to our problem… Designers are the Swindlers, Comps are the Cloth and well… the Client is the Emperor.

A well intentioned client who only cares about having the best website, hires a designer. That designer promises to create a comp and tells that client that only people who are hopelessly shortsighted will not be able to imagine the interaction and layout across browsers. All of the clients stakeholders and decision makers pretend to see the interaction and how the the works on all the devices for fear of appearing unfit for their position, and the client does the same. Finally after many comps are made to the client's illusionary satisfaction.

Can anyone guess who the kid is? The comp is passed off the the developer. The developer is the only one that doesn't pretend to see the imaginary interaction. The developer is the kid.

Yes, I have taken huge literary license with my version of the Emperor's New Clothes, but the takeaway here is that what we as designers need to be in reality is not the swindlers, but we need to be the voice of the child, because when sight becomes insight, it prompts actions. When we stop peddling our pictures of websites, and start calling it like we see it. A comp leaves everyone involved, naked.

The King & the Screen: a match not made in heaven

The king and the screen are not an ideal match. We borrowed this solution from print but it never was quite right, and our mobile landscape is only making this more evident. It's like taking your cousin to the prom, people won't know you are related unless you tell them, however, it just not quite right.

Now What?

We need to change our vernacular.

O.K. but what are our deliverables? Discussions are nice, but what do you sell?

For our sake, we are going to assume you have done all of the good upfront work, you have kicked off your project with the client, you have asked questions and have identified theme and similarities from those answers. You understand the site's content and priorities. You have all of the research done and a creative brief in hand to start the visual design process, this is the point where you would go into photoshop and start pushing pixels.

Style Tiles

Style tiles were developed by a designer, Samantha Warren, they are a visual web design process for communicating the essence of a visual brand for the web.

It contains visual elements such as fonts, colors, and interface elements that are meant to show a client how a design feels. What you don't see is content, viewport, layout, because those things are variable. You only see the elements that are core to the visual design.

This gives you feedback you need… about design. Have you ever presented a comp of lets say a homepage, and instead of seeing your design… the monochromatic color scheme you used with bright pops of hot pink, the flat design aesthetic paired with texture of lace to create a sense of contrast, and the careful consideration you used when pairing serif and sans-serif typefaces… instead of seeing all that, instead of seeing the design, they say to you… “where is my about page link?” Instead of showing exactly where every element is going to be places on the page, in a certain dimension, style tiles show just the interface options so that you can zero in on the clients preferences for design.

Another benefit to using style tiles is that they are incredibly easy to iterate. How many of you comped out a website, presented to the client, only hear something along the lines of “I hate the color blue”, when blue is a prominent color in your palette. Then having to go in and change that in every comp to represent to the client. When working with style tiles, you can very easily implement changes without having to spend the time to update multiple comp files which is a huge time saver.

Element Collages

Element Collages are similar to Style Tiles in the sense that you are only showing things such as fonts, color, and interface elements, however it more of a freestyle photoshop canvas that contains a collection of elements you are feeling good about. Maybe there are a few different options for each element. This is then used for getting feedback from the client. It's not really changing what we do already, many designers start this way anyway, it's more about involving the client in the process sooner, getting critique instead of a signoff.

Pattern Library

Both Style Tiles and element collages at their core, are about creating a design baseline. If you need to compile all of your learnings and designed components into a deliverable, creating a style guide or pattern library is a great tool, for both the client and the developer. A style guide is a document which details all the various elements and modules. It contains things like color palette, and typography. It would contain objects and components like buttons, call-out boxes, forms, icons, etc. A style guide would also document various interactivity, things such as dropdowns, modals, or tooltips.

This is the point where things get divisive. Web designers who code, and those who don't.

Learn your medium, learn to code

As designers who create things for a specific medium, the web. I feel that we should all should have at the least a basic working knowledge of presentational HTML + CSS, the languages that display our styles and designs. To what extent of knowledge is up to each designer separately, but it should be at least to the extent you can work collaboratively with developers, and communicate your design. If you as a designer have a functional knowledge of HTML and CSS, you can create your Style Guides and frontend styles in code. There are many resources for designers learning to code, Treehouse is great.

Prototypes and Functional Wireframes

These guys show interaction, layout, UX, content hierarchy, and viewport. Once you have the coded out wireframe in a good place, you can begin to take your Style Tile, Element Collage, or Style Guide and begin to layer in the visual baseline you created. Because you have included your client in the process up through this point, none of what they see should be a reveal, and what they are now interacting with, is a prototype in the actual medium in which it will live, the browser. And you will be applying your time and efforts towards work that will be used in the actual product, a website, instead of hours spent in photoshop creating pictures.

If you are a designer that doesn't code let's assume you are working closely with a developer. This means working collaboratively with our development counterparts, not just handing over .psd's. You can create flat wireframes and put them into a tool such as InVision so you can show a little of how that experience flows. Or just sketch out your ideas and open the dialog between you and your developer.

Revisiting Our Goals

Let's revisit our two main goals from earlier. Only this time lets use our comp alternatives to serve those goals.

First, for clients.

Instead of having to imagine the function and interaction, we can facilitate discussion and build prototypes, utilizing our design baselines. They will experience their design in the browser where their website will live, instead of just looking at a picture of their site.

Second, for developers.

We are bridging the gap, no longer can we rely so heavily on the comp as a map to communicate our intentions and assumptions. We have to work side by side with developers. Or, embrace our medium and learn to bring our designs into the browser ourselves by coding.

We need to educate our clients.

One of the biggest objections to changing our design processes and deliverables is how to explain all of this to our clients. I think that explanation varies from client to client, depending on the type of client you are working with. Some are more rooted in traditional comp workflows and will need more education and coaching.

Mike Montiero is a Design Director @Mule, he wrote “Design is a Job”, I highly recommend it to any working designer or those who work in the business of design. In his book, he says,

It's your job as a designer, and a communication professional, to find the right language to communicate with your client. When you say a client doesn't “get it” you might as well be saying, “I couldn't figure out how to get my point across. I am a lazy designer. Please take all my clients from me.

Mike Montiero

Trust is at the core of change.

Regardless of what process your clients are familiar with, the key is trust. If you have done the work to really set up and kick off your project right, you will establish that trust from the beginning. The rest is really continuing to build that trust along the process.

The comp has had a long reign as our singular means of communication. For some projects it might be the best solution, for many it might not be at all. The landscape of our medium is changing everyday and that's what makes it so compelling and exciting to be working in our industry today. I hope some of the concepts and tools will be useful in your next project or help your workflow.

Resources & References