Attack of the Frankencomp - The Case for One Comp Design
June 15th, 2009I’m a big proponent of the one comp school of design. Last week Andy Rutledge did an interesting writeup on the topic and bashed the idea of designing multiple comps. This post started out as a list of things I agree with and don’t agree with. After a second and third reading I can’t find anything I disagree with (other than his tone).
You can divide designers up into two groups. The first are the problem solvers — we can safely put Andy into that group. The second are the decorators. For the sake of argument I’m going to put a younger version of myself into that category.
Andy’s main point is simple: If your goal is approval you’re design will never be successful. The younger Brad was eager to jump in and start designing. I wanted to get in a quick phone call, maybe get an idea for what sites the client thought looked cool and then open up Photoshop to see what i could do. The problem solver takes a different approach. It’s built around the users and their needs.
Andy never brought up a problem I had with doing multiple comps and that was how much MORE time it took. You would think that giving several options up front would push someone in a direction more quickly, but that wasn’t often the case. The client was picking colors and design elements from all the comps and I was building something new with each iteration. The new designs never looked as good as the originals because good design is holistic, not patched together. I would just wind up with a Frankencomp with a bunch of unrelated pieces thrown together.
The worst part of the Frankencomp was that it got the myself and the client focused on the window dressing and not the design problems we were trying to solve.
Here is what I do now. I put a lot more work into the pre-design. You can read a more detailed version of my process here. There is a lot more research upfront, starting with the content and working our way out. On a recent ecommerce site design I sat down with the client to talk about why they had such a high abandoned shopping cart rate. We talked about how their business worked off-line, how they took orders and how they interacted with customers. We quickly figured out that the reason why the shopping carts were abandoned was because the people creating the orders needed approval before placing the orders, they were building quotes. Armed with that new information we set out to build a site that dealt with their specific set of problems.
Another great example is the recent design of Microsoft’s Bing Travel site. The layout, fancy ajax and functionality is very similar to Kayak.com. Douglass Sims noticed something odd about the two sites. He was getting lower prices on the Bing Travel site. When he clicked through he couldn’t find the lower rates on the airline’s sites. Bing’s site wasn’t pulling over up to date rate information. When Bing travel was designed it pulled all the cool design functionality of Kayak.com over but they didn’t understand all the problems that Kayak.com has been working on for years.
What it comes down to is that you have to first have to understand the fundamental problems the design is trying to solve. From my experience creating a bunch of comps to see what sticks isn’t an effective design approach. That’s not to say that you shouldn’t experiment and try new things, or even present several solutions to one problem. But be careful thinking that just throwing out three comps at the beginning of every project is going to solve a problem you haven’t defined.
