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!
Mike Krieger
on 31 Dec 08Great post—I like how you tied Getting Real back to your real-world experiences with clients.
I’d add that there are artifacts that useful internally - for example, not a full-blown hi-fidelity wireframe, but a quick paper sketch - that would make little to no sense to a client (“this looks so crappy!”) but might spark ideas & suggestions within the design team. Wireframes (built just to be wireframes) sit in an awkward spot where they’re neither great for internal communication / storytelling (you could have just started doing a rough HTML implementation, and done rapid iteration on it), nor are they particularly good for client / end-user communication.
Matt Radel
on 31 Dec 08It sounds like your early experiences got tripped up by failing to manage client expectations. You educate them to understand why the planning phase is important and a necessary step. We’ve had good success at my company by presenting site studies along with research and wireframes. It seems to make everyone happy. :)
Arthur Klepchukov
on 31 Dec 08If you skip wireframes and mockups, where and how do you do interaction design & information architecture?
Jeremy
on 31 Dec 08With respect to the last point (nothing is permanent), I find that it helps to choose an architecture that makes changes easy after the launch. That way, you don’t have a built-in resistance towards making those changes just because it’s a pain in the butt to retrieve the files, edit them, and upload them again later. Personally, I’ve been really happy with using the Squarespace CMS for this purpose, though I know some folks speak very highly of GoodBarry, too. These obviously aren’t ideal for all types of projects, but they can certainly take the pain out of those edits and refinements that might otherwise be met with a lot of resistance once you’re past the launch date. Side note: I originally found both of those companies on The Deck :)
Tim Grahl
on 31 Dec 08What I took away from this…
As a two man dev/design firm, it’s nice to know the big boys getting the Target contracts do plenty of fucking up as well :)
Jamie: We use Basecamp for client interaction. Not sure I want to introduce them to GitHub but in your explaining in how you, Jason and Ryan interacted on the design, it sounded like something that could also be done in Basecamp. Could you write a tutorial of how you would use Basecamp to interact with clients in a similar way?
JD
on 31 Dec 08Matt Radel, I don’t mean to say ditch your process and replace it with Getting Real. The Target site was successful and built using that process. The Crate and Barrel site continues to do well during these tough economic times, and they use that process I spoke about above.
If your process works for you that’s great. If you’re looking to improve it a bit then check out Getting Real. Applying Getting Real principles might move the process along faster. You might start seeing positive results sooner.
JF
on 31 Dec 08Tim: Git is a version control tool, it’s not a collaboration tool like Basecamp. They are different tools for different things.
We use Git so we can all work on the same files and not overwrite each other’s changes. We can roll back changes or create branches for explorations without affecting what someone else is working on.
JF
on 31 Dec 08If you skip wireframes and mockups, where and how do you do interaction design & information architecture?
We don’t make a distinction between design, interaction design, wireframing, and information architecture. We don’t need one to do the other since they’re all the same thing. “Design” is about interactions and structuring information. There is no separation. There are no boundaries. It’s all one in the same.
Keith
on 31 Dec 08Always love hearing about the design process of others. I’ve got a few comments/questions/observations about y’all’s take on the design process.
In discovery we often do briefs (creative, project, etc.) but we really do try and keep them brief. Very brief in fact, mostly just high level overviews to keep everyone on the same page. We don’t really do things like mood boards and such unless a client insists on it. I do find those things valuable to a certain extent, but like you, think real designs and iterating from there are a better way to go.
We don’t generally do style guides (well, sometimes we’ll do them at the end of a project, again, if our clients want them) but we do usually do an extensive wireframing process. That process can, and often does, go smoothly but I’ve always wished there was a better way to show and design interactions. We have some of the same kinds of problems with wireframes you mention here.
I’d love to jump right in to do prototypes, but it seems like there is a barrier there as far as tool available (know of anything good??) and getting our interaction designers to actually change their own processes. Well, and honestly our clients usually expect wireframes and it’s hard to get them away from the “4-D” process as well.
I have noticed that our “wireframe process” never seems to end. We just move it along past wireframes, into design comps and then usually into the final deliverables.
As such I’m a big fan of moving from wireframes or comps into HTML/CSS as quickly as possible and having a fluid enough process to keep iterating. The “problem” we often have is that our clients aren’t often comfortable with that. They want to know exactly what is going to be done, when it’s going to be done and how much it’ll cost.
Figuring out how to adapt our process and at the same time get our clients to buy in is a challenge we talk about every day. I’ve talked with JF a bit about this in the past, the biggest hurdle to a more productive design process is the client/designer divide.
JD
on 31 Dec 08Keith,
Thanks for your comment. One of the promises of wireframes is to catch issues early before an investment has been made in writing HTML/CSS or cutting graphics. In my experience changes in architecture are requested mainly when Design and HTML are nearly complete. This wouldn’t be a problem if it didn’t happen so close to the deadline. Again, this is my experience.
What would happen if you started roughing out HTML/CSS and Design during the time when you’d normally be creating wireframes? You might end up with code and design that you throw away. But that’s going to happen anyway right? At least you’re getting it out of the way sooner rather than later.
Mitch
on 31 Dec 08Great post, very insightful! Thanks
Jon
on 31 Dec 08The problem, of course, with your lack of process is that your products reach a point of largeness where you simply can’t “wing it” anymore. Basecamp is a great example, as it drives me and everyone I know who is forced to use it absolutely and completely crazy on a daily basis. There is a simple lack of quality and coherence to the product, largely due to your lack of reflective design process over time. The cost of switching now, however, prohibits, me from embracing a better design.
JF
on 31 Dec 08Jon, I’d love to hear exactly how Basecamp drives you and everyone you know completely crazy on a daily basis. I’m curious where we’re not meeting your expectations.
However, I don’t want to turn this thread into a discussion about Basecamp, so please shoot me a specific, detailed email with your concerns. jason@37…you know the rest. Thanks.
Arthur Klepchukov
on 31 Dec 08JD,
“You might end up with code and design that you throw away. But that’s going to happen anyway right? At least you’re getting it out of the way sooner rather than later.”
Isn’t that wasting time? A wireframe, given a good tool like OmniGraffle, is easier and faster to create than HTML + CSS. Or do you find that, with experience, you iterate just as quickly with HTML + CSS as good wireframing tools?
JF
on 31 Dec 08Arthur: The point is that you don’t really know if something is right until you do the real thing. You can spend a lot of time on a wireframe, but until you “put the clothes on” you don’t know if actually fits.
My experience has been that abstractions like wireframes lead to an illusion of agreement. Clients (and designers) think they like the structure, but they don’t really know until they see it fleshed out. Only then can people really evaluate if it works or not.
Humans aren’t good at filling in the blanks. Wireframes are blanks. Real designs aren’t. The quicker you can get to something real (A design in HTML/CSS) the sooner you can reach real agreement.
You’re going to have to iterate no matter which direction you go in. We think you’ll find a lot more value iterating the real design than iterating both the wireframes and the real design. The longer you can work on the real design, the better it’s going to be. Your release version will really be version 1.5 because you’ve been working on it for a while.
pwb
on 01 Jan 09I’ve become a big fan of Balsamiq. The fact that the objects and text look handwritten eliminates all the pixel-perfect sidetracking.
Austin Schneider
on 01 Jan 09I love these kinds of posts.
Adam
on 01 Jan 09Second the shoutout to Balsamiq!
matt
on 01 Jan 09@JF: “It’s all one in the same.”
I think you mean one and the same. Wouldn’t want you to go around using phrases incorrectly.
Marisa Peacock
on 01 Jan 09I don’t use basecamp or any 37 signals products, but I am a web designer and read the blog. I am an office of one. Without a style guide, i have a lot of our internal departments wasting a lot of time (theirs and mine) with stuff that falls outside our marketing strategy. This isn’t meant to limit innovation, as we work within a tiny, if not non-existent budget, so it tends to makes us more inventive and strategic with our ideas.
Style guides are not meant for designers, but rather for non-designers so they know that using hot pink or comic sans isn’t an option. Non designers will save themselves lots of time if they stop wasting their time giving designers layout and just stick to content.
I think style guides are very useful because so many people in other domains and expertise have no problem telling me how to design, but yet I would never tell them how to do their jobs.
Designers, especially those of us who are self-taught, are often considered to be less than experts, when most of our clients are not web savvy or have any idea about good design. My job is to make good design better, to make something great out of little and improve usability so that users want to use whatever is designed.
I am a huge follower of Getting Real, and I have given copies to a lot of the people with whom I work. Yet, I think some structure is necessary, if only to discipline others so that you can work for effectively and efficiently. Style Guides let this happen.
Joshua Blankenship
on 01 Jan 09Is it really? HTML and CSS aren’t exactly massively difficult things to write/build, especially with talented folks on your team and good tools. If it’s all going to end up being HTML/CSS anyway, why not start there (albeit roughly)?
David Newbury
on 02 Jan 09I think a lot of the issue is that 37signals has a team of people who know roughly what is and isn’t possible, and who knows roughly what they want, and who isn’t stuck working on a fixed budget/timeframe for completion.
I’m far more used to working with people who don’t know what they want, or they want impossible things, and they want me to tell them that it will take exactly 40 hours to do it. Wireframes and designs are ways to make sure that I know what I’m committing to, and that the client knows what they’re getting. In a perfect world my clients would trust me, and they would give me the freedom to come to them with a close-to-finished idea, and tweak from that. But that trust only comes with experience on their end.
I think a lot of the differences come from the difference between a small, focused team of talented people collaborating on a goal, and a inexperienced client trying to express poorly-formed desires and get the most from limited resources.
Mike Gowen
on 02 Jan 09It can be difficult (but not impossible) to adopt any sort of iterative process within an agency environment. Unless you’re on retainer with the client (or any sort of longer term relationship) you’re stuck with having to limit yourself to one single big launch. When you’re working on your own product, you can launch the core foundation, and build up over time. However, with a client, unless you negotiate a long term relationship, there will be more pressure to “nail it” on the first release. Obviously this is unrealistic. Furthermore, this can be a hard mindset to shake for an agency moving into building their own products.
Good clients won’t need any convincing that a long term relationships will give them a better product, and won’t see it as the agency trying to extract cash. Other clients may need this illustrated to them.
Rob S
on 02 Jan 09I’d love to find a way around mocks and/or wireframes. Our problem generally lies around our QA process and laying a foundation for testing the software itself.
How do you find your way to transferring the knowledge or backgrounds across different teams without a coherent process?
RS
on 02 Jan 09For us it’s not a problem because we are only one team. And I highly recommend the style of starting a project with as few people as possible. In the case of software design, the bare minimum is two people. You need a UI designer, who is like the eyes that see what to build. And you need a developer, who is like the legs that walk you there. These two are enough to get some software running that addresses the problem.
RS
on 02 Jan 09Mike,
Iteration doesn’t mean long term. You can (and should) iterate in the short term as well. Iterating means delivering smaller pieces and getting feedback on each piece before building the next. You can still have a big launch, and you don’t need a longer relationship. The question is, how do you communicate and check your work each step along the way toward your launch.
Viktor
on 03 Jan 09@Jamie, Awesome post I love Getting Real.
@Mike Gowan, I think you’ve nailed it there. As someone whose worked both at a start-up and at an agency, I totally understand the constraints involved in implementing getting real.
I feel if there is not any iteration in the build you tend to run into problems. I’ve found it’s most cost effective to do a combined discovery and planning phase to cut the lead time down but get agreement on the bigger issues. Once you have buy in you build the core of the web site/app and iterate on it.
I think sometimes there’s a tendency to get way too lenient with planning when undertaking iterative forms of development. There should still be a rough sketch of the core idea before jumping in and coding. It doesn’t have to be elaborate, just enough to get the ball rolling and get the basics down. Axure is an excellent tool that let’s you wire-frame out an idea quickly.
If you are part of a small team with less constraints (Not involving large scale client projects) then it is definitely easier to be more iterative from the start. I think starting with a CSS. This is not as big of an investment as diving into Ruby on Rails directly.
Mat
on 03 Jan 09Jamie. Enjoyed the post and the comments.
We used Getting Real to drive the development of our own app, so a lot of what you said resonates with how we worked before launch. We described designers working in tandem with the team as “extreme designing”, which was a bit tongue in cheek but got the point across.
I do think that it is rare to have a situation where a team can work as openly with the code as you do at 37s. You are fortunate to have a team where everyone has technical ability and can work on designs at code level.
Many designers want to be open and get early feedback from clients, but they can’t expect their clients to dive into a shared codebase. In fact 99% are probably working with clients who have never seen a line of code.
Styles guides or wireframes may be right for some projects. Some teams may prefer PSDs or HTML/CSS. But no matter what the methodology designers still need to get visual feedback from clients and that can often be the biggest hold up. Arguably it’s as easy to waste as much time managing client review as it is on “unproductive” steps upstream in the design project. This is especially true when designers are in different locations or even time zones to their clients.
Ok, so I am in danger of taking an unseemly step onto the ProofHQ soapbox, but I would love to get your feedback on how a tool like ProofHQ (http://www.proofhq.com) can streamline the design review process for teams where not everyone can cut code.
CJ Curtis
on 04 Jan 09Whenever I’ve encountered wireframes (having to do them), they were actually being requested by clients who really didn’t understand what they were for in the first place. They were just a line item in the marketing handbook. I’ve never found them particularly helpful, simply because they are not a realistic depiction of the system.
I don’t go the HTML route either. I prefer nailing down the look of the site to get the client’s trust and get them to support my ideas. Then quickly build different click paths based on these rough designs. It can be a little messy, but once testing is finished, you have all the design assets needed to begin building the site immediately, and you haven’t wasted a second of development time.
Paul Souders
on 04 Jan 09Joshua Blankenship already touched on this but I’ve repeatedly found the opposite to be true. I once had a client project (where my role was solely “information architecture” and “interaction design”) that entailed the production of hundreds of wireframes (with accompanying sitemaps and work flows) for a massive extranet. In the end we found it fastest to communicate and iterate (with the client, creative team and developers) via PHP templates with reusable components, around which I’d constructed a kind of clickable Potemkin Village.
The main departure from the Getting Real methodology was that our village’s appearance was color-coded boxes instead of the final creative direction. (Sidebar: I actually had a secret stylesheet that could render the wireframe HTML using the final site creative, but this was deep-sixed as counterproductive, as a large percentage of our contracted billable hours were for screen-by-screen Photoshop comps and flat-file HTML.)
Jamie: this is an great post and a theme I’ve been harping on since the experience I describe above. But I think what you’re really getting at here is the difference between client work and your work. This is a better lesson for potential clients than for agencies (in fact, it should scare the bejeezus out of agencies). Bring as much work in-house as possible. Own the process and enculturate your designers, don’t pour money down some agency’s Process Hole or waste time getting their designers to understand your cultural DNA.
After almost a decade in agencies and software shops, I’ve worked in-house for a nonprofit for the last 18 months and I’m shocked how much more productive (and creative!) I am now, for less effort and grief.
JD
on 04 Jan 09Paul,
Thanks for writing about your experience. Another point of Getting Real is to avoid silos at all costs. Silos, to be clear, are when different departments work independently of each other. You can look at an Agency/Client relationship in this way.
If you are at an Agency you should know that only the most self-aware Clients will give you access to the people who really do the work. Chances are that you’re meeting with Creative Directors or Art Directors or Directors (in general) that don’t have a lot of hands-on experience with the work. They don’t know what is or isn’t possible. It doesn’t mean that they’re not qualified. It just means that they’re not responsible for writing code or creating PSD mock-ups, etc. They just want to be “wowed” by your concepts.
If you find yourself in a meeting with too many “Directors” ask about people like Paul here—the Designers, Senior Designers, IAs, Developers and QA folks. A few working sessions with the real builders and architects will bridge the gap and get you all to a real solution much faster.
This discussion is closed.