I’ve only known one method for approaching a Design project. There are many variations out there, but it can essentially be broken down into 4 steps: Discover, Plan, Design/Develop, and Deploy. It didn’t matter where I worked—agency or internal design department—these were the steps, and I didn’t question them.
Then 37signals published Getting Real, and I wondered if this might be a better way of approaching a project. I’d like to share with you a few stories from past Design projects while reflecting on how Getting Real would have helped. I’ll also share some insight into how the process here at 37signals works.
Discovery and Brand Immersion
In the late-90’s I worked at an interactive agency called Organic. There I worked on a redesign of the Target commerce site with a talented group of designers and programmers. At the beginning of this project we kicked off what we called a “Discovery phase”. In the span of 3 weeks we visited Target stores, created a war room with magazine clippings, made a Ven diagram and brand matrix.
Our Art Director created a beautiful Creative Brief document that was presented to Target executives in Minneapolis. The presentation was a bust. It wasn’t because our findings and research were off the mark. It was because we didn’t have any web page designs to show. In 3 weeks we managed to tell them exactly what they already knew while also burning through 15% of the budget.
A Discovery phase is sometimes a necessary thing to do especially when an outside agency is involved. The approach, however, can be abbreviated. Chances are there is an internal team at your client’s HQ that has come up with all of the ideas already. Why not collaborate with them so that the first presentation consists of actual Design treatments? You can effectively eliminate a step in the process, trim your budget, and start delivering results for your client earlier. A Creative Brief is nice but real designs are nicer.
Wireframes and Style Guides
At Crate and Barrel we followed the same steps except that we bypassed Discovery and went straight to wireframes. Presenting wireframes often solicited yawns. It was difficult for Merchandisers or VPs to understand exactly what they were looking at. They wanted to see Designs like everyone else. When the presentation was more real—even a Photohop mock-up—it was easier to get feedback and direction.
Imagine if Information Architects and Designers worked together with Developers to create a working section or feature of a site. Wireframes can be part of that process but don’t have to be presented. The more real it is the better feedback you’ll receive.
Wireframes also serve as a contract for the UI Design. If it is in the wireframe then it is in the design. If it isn’t in the wireframe then it isn’t in the design. We usually ended up changing the design in ways the wireframe dictated not to anyway. A similar thing can be said about a style guide. You spend all your time defining what you can or can’t do visually yet in the end you break your rules anyway.
When I first got to Crate and Barrel I asked if there was a style guide I should follow. Alessandro, the Creative Director (one of the coolest guys I know), told me there wasn’t one and it was unnecessary. To have a style guide would doom any future graphic design to be inflexible. I thought this was so cool. Here’s this great established brand with such a powerful graphic presence yet there isn’t a style guide.
Open Source Design
One of the most difficult things in life is learning to share. I have a deep respect for the programmers at 37signals. All of them come from the open source world where sharing work is a given. Designers by nature don’t like to share. At least I don’t. It’s hard to see your work take on a life of its own. In fact that’s the reason why I got out of the agency life. I hated releasing work to the client only to see it a year later in a bastardized state.
Designing at 37signals requires sharing. While Jason, Ryan, and I all live in Chicago we often are working in separate locations. In creating the Highrise marketing site we used Basecamp and Campfire to review design directions. But what really makes this process different than others is we’ve gotten to real HTML much faster than I ever have before. All this HTML is in a Git repository for everyone to access. I can make changes to graphics while Jason makes changes to copy. The result is that it feels as though we’re sculpting the site. We’re not throwing PSDs back and forth. We’re updating HTML and looking at the real thing.
Since launch we’ve also been making small adjustments to the site. In fact that was part of the plan, and we’re still making adjustments. This has been the most iterative project I’ve worked on. I realize that it is smaller in scale than a commerce site redesign, yet there is no reason why such iteration can’t occur on those projects too. The time that it takes to do brand research or wireframe docs takes away from this iterative process. These quick iterations are great ways to constantly improve the site.
Getting Real is a great way of working, but it’s also scary. You’ll make mistakes and some tough decisions along the way, but you’ll be happier with the result. Remember that if something is not working you can always change things—get rid of stuff. Nothing is permanent!