I don’t know your design process, so, it would be foolish for me to generalize. For the sake of this post however, I’m going to have to. When I’m finished you can feel free to tell me that: (A) I’m a moron, (B) It won’t work; or, (C) This is how you always did it anyways. Any of those are fine–including (D) You might be on to something. Regardless, here’s my hypothesis.
The masterpiece mentality
Anyone who worked with me five years ago would attest to how painful our creative process used to be. This was the byproduct of good intentions run amok. Ultimately, I held to the notion that we had to do everything we could to build the best work possible. In my mind, this involved exhausting every available option to ensure that we hadn’t missed anything.
As a result, we employed an approach in which we’d create as many options as possible for a project, then scrutinize each element, run variations, and then refine and repeat. Here’s an example:
– Designer creates 200 sketches of logo options
– Select 10 workable options
– Refine and select 2-3 of the best options
– Run typographic variations
– Show client selected option
– Refine icon, draw type, fine-tune letter spacing
– Test in varied settings (i.e. size, application, reverse)
– Create final artwork
– Develop identity (and so on…)
To be blunt, this way of working sucked. We multiplied the labor requirement unnecessarily, and left ourselves with an inflexible element. This wasn’t our intention; in fact, we thought that being this particular was a good thing. We believed that it was best to refine elements along the way, and allow the rest of the project to work around them.
What if you need to change it?
The problem with the “masterpiece mentality” is just this. While we struggled to create a “gem”, we in-fact tied ourselves to that specific implementation… and on occasion that solution turned out to be an anchor. After 100 hours on the logo, what was our response going to be if it didn’t work on the website? (And don’t kid yourself–some logos will not work well across the board.)
Generally, this left us either trying to hack it into shape, make the other materials adapt to its limitations, or start all over again, throwing away all of the time invested to date. Repeat after me: “dumb, dumb, dumb, dumb”.
Now, there are times to run variations. Typically, I find these times to be when things aren’t working. When they are, however, we don’t necessarily need to find the “perfect” one. Think of searching through 5,000 photos to find the “best” one. Looking for perfection is time consuming; additionally, your idea of what this “perfection” is may very well change.
Designers are detail focused, and there’s nothing wrong with this, as long as we concentrate on the right details at the right time. Think of it this way: you’d be a fool to install the sink before the foundation is poured; nevertheless, as designers we do this all the time. We get excited about one idea before we know that it’s really the most workable one, and we start polishing out of pure energy and excitement. This makes for bad design solutions.
We need to remind ourselves to step back and ask if we’re concentrating on the most appropriate points.
Agile development for designers
In the software world there’s been much talk of agile development. This largely boils down to building something quick, getting it to users, and then correcting mistakes. By contrast, larger organizations have often worked with a “waterfall” method, in which they perfect an application and then ship.
Although agile development has its shortcomings–including the possibility of making a more public mistake, it has considerable advantages. It’s fast, it’s cheap, and it removes a lot of the obstructions faced by more rigid methods of working. Tempered with some added internal testing, it’s a really smart approach to apply to communication design.
Over the past year, I’ve worked extensively on the user-interface design of MakeFive. Now, if you haven’t used the site, I’d ask you to try it out. (It’s a rather fun way to spend a few moments.) To the point, however, MakeFive has “schooled” me in a way that no other project has. Points that I felt needed to be solidified early on often needed to be discarded later. I could have let this frustrate me, but instead learned to concentrate more on our end-goal. As a result, we’ve changed our method of working at smashLAB (for the better).
My seven suggestions for enabling agile design
1. Generate lots of ideas (fast)
You sometimes need to cover a lot of conceptual ground in order to best understand the problem. This is fine, but make it snappy. (i.e. Can 100 options be generated in an hour using only the most crudely drawn sketches?)
2. Employ a small team that talks
Toiling away on one’s own is hard; worse yet, it brings the even more difficult moment when an art director must review the unfinished work. This creates stress for both individuals, and often results in good ideas being dropped due to mis-communication. As such, idea generation should be worked on as a group of two or three individuals who feel comfortable contributing to the discussion as equals.
3. Remove ego
Award shows have taught us to be clever. This leaves us trying to do something bigger than what we actually need to accomplish. Cut that bullshit out. Turn-off any thoughts surrounding awards, annuals, portfolio development, and concentrate on what will get the job done. (Trust me, this is way easier and far more effective.)
4. Embrace workable solutions
Don’t make this a quest for perfection. If it doesn’t work, you have to run more experiments, but if it does, you are probably best to just keep refining your idea.
5. Discard with impunity
If it doesn’t work, “turf it” quickly. This is actually easy to do in an agile context, as the time investment is nominal. Discarding an option after working on it for 100 hours is difficult, but with a five-minute pencil sketch this is hardly the case.
6. Utilize broad gestures and leave finishing work for later
If you’re working on an identity, use placeholder elements, (regardless of how clumsy they may look) and create drafts of all major elements as quickly as possible. Run the theme across signage systems, corporate attire, ads, cars, stationary, et cetera. Nothing has to be perfect here; you just need to see how it adapts. Later you can clean all of it up. (Here’s another way of looking at it: Don’t sand the surface until you’re done cutting.)
7. Prototype and test
Take your roughs and get them out to people, asking specific questions. Don’t ask whether they like it; concentrate on polarizing questions that are limited in subjectivity. For example: “Can you read this text clearly from across the room?” or “Would you characterize this as elegant or fun?” The purpose of this is to get clear feedback that will allow you to fix bugs and avoid circular debate.
Does it work?
Put plainly: yes. I’ve experienced it myself, and I’m never going back to our old design process. An agile approach is surprisingly fast, easy and flexible. (It also reduces my need to drown myself in scotch at the end of the day.) In large part, it leads us to consider the macro before the micro, and apply our detail-oriented tendencies at the appropriate time.
If you find yourself struggling with clients, frustrated at the end of the day, or running over hours on budgets, I ask you to try this method of working. You can “care” about the work just as much as ever, but you’ll reduce stress, simply by working in a fashion that adapts better to the unknown.
Additionally, your clients will appreciate this approach. None of this is about taking shortcuts. It’s about eliminating unnecessary work. You can still obsess over line-spacing, paper stocks, punctuation and color balance. Just do it at a time when it’s safe to do so. Your client’s investment isn’t to be wasted on half-cocked directions.
And remember. It doesn’t have to be a masterpiece; it just has to work. That’s all.
BTW: We’re just about to launch a new site and would love for you to visit it and spread the word. It’s called undrln. In a nutshell, it’s Digg for those of us in advertising, marketing and design. As such, it’s content that you’ll likely find relevant given what you do. (Oh yes… It’s also not quite as ugly as Digg.)
Pingback: eismann-sf » Reflections on Agile and Communication Design
Pingback: Design is all about Theory
Pingback: E-Commerce Blog By Solid Cactus
Pingback: Can a Marketing Agency Be Agile? (Inside Forty)
Pingback: UX & Agile Articles » agilemusings.com
Pingback: Can a marketing agency be Agile? | Forty
Pingback: Agile design: what we've learned - Forty
Pingback: Testauskortti on Natsikorttia väkevämpi - Mainostoimisto MEOM, Jyväskylä
Pingback: Agile design: what we’ve learned - Crowd Favorite