Friday, December 12th, 2008

Applying agile principles to communication design

Applying agile principles to communication design
Email to a friend Comments (41)

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.)

Follow @karj to hear about these posts first.

Comments & Trackbacks

  1. Rob says:

    As always great post. I'm always paranoid about my workflow as I am a sole designer in a tiny in house studio, so I tend to exist in a bubble in the work environment. I love hearing about others processes, and it seems to be one of the most guarded secrets. Thanks.

    Can't wait for the new product launch.

  2. Wil Arndt says:

    Call me dim, but I don't really see the difference between how you "used" to do it and how you do it now. Other than you do it faster. Both methods described are a funneling of work and winnowing of options into a final workable solution. Maybe I'm missing an important implication in the old method?

  3. You're right Wil; it is pretty similar. That being said the difference, even though small, is notable.

    I largely sum it up with "finish all of the cutting before sanding". In the past we'd get one part highly refined and then learn that it didn't fit in the overall picture. Now we step back for longer, and refine when it's safer to do so.

  4. This is just what I needed to read today.

    I've been doing business just like you did seven years ago, only I haven't even tried changing the way I worked until recently. The process becomes too hard, and - like you stated - the work often becomes an anchor.

    The advice and points here are right on. Thanks Eric, really.

  5. Sean Stiller says:

    I couldn't agree more. Admittedly I'm still in the former category to an extent. It feels very natural and intuitive to labor over the first few ideas that come to mind, and automatically assume those are the cream of the crop.

    As it concerns interactive/web design in particular, one issue I've found is how tempting it is to start building mock-ups in Photoshop TOO early in the process, which has the horrible effect of stunting ones thinking far too soon.

    Just out of curiosity, how many people here use grid systems (i.e. 960) during the sketching process?

  6. Joey Pfeifer says:

    Interesting article, Erik.

    I don't have a whole lot of experience, but your first suggestion doesn't sit right with me.

    "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?)"

    I take issue with this, at least when applying it to logo and identity design. There's a reason why the best identities can take months, even years to make. Sure, some are conceptualized quickly, but good logos aren't produced, they're cultivated. Maybe clients don't recognize this?

    In the past I've received design assignments along the lines of: "Joey, I need to you to come up with a logo within the next two hours." Or: "Okay everyone, put together some logo designs, at least five from everyone here, and we'll send the bulk of them to the client at the end of the day." In my head, my natural response is "Are you fucking joking?" But, unfortunately, this is how it seems to work for a lot of people and companies... and clients seem to *expect* it.

  7. I hear what you're saying Joey, but I'm not proposing that anyone side-step hard work. My proposal is to look at the big picture, test options rapidly, and then refine. That doesn't mean less exploration, it just leads us to using our time better.

    Logos are a good example of this: many people start with these, and want to do more with them than they really should. This is simply a matter of confusing a mark with an identity system. As a result, logos end up looking like pictures when they in fact should work more like symbols. (They are just a small part of an identity system.)

    Most of the logos we work on still take around 50 hours to complete. That being said, we certainly don't start our process with the logo. That's creative suicide. We start with lots of big general ideas for the brand we're working on, and leave the fine-tuning for later in the process.

  8. Dabitch says:

    I don't do pure design very often (it's been year since I sent a corporate identity out the door) but I see how your new way of doing it with the thumbnail approach is faster, and funnily enough, it's the way I do it.

    Printers hate me, so I don't print if I can help it, so when it comes to working up a few examples as in "this is how the letterhead will look and this is the envelopes", I'm doodling these on paper and asking around before I even look at my computer.

    The only thing I would like to add to your system is something Paul Arden taught me. He told me when you're stuck, change your worktool. If every idea you have is coming out rubbish with the usual black marker, use an oil crayon instead. Or soft pastels. It's amazing how much this simple thing really shakes up your thinking and gets you out of a rut fast. Try it.

  9. Agreed. Then of course, almost everything Paul Arden said sounds pretty insightful to me.

  10. Dan says:

    Thanks for this Eric. I'm down with point no.3 about removing ego – this is probably the biggest barrier between a brief and a workable idea! It's hard to let go of in the early days though, when you're trying to make a name for yourself and bring something new to the table.

    Have you got any tips for how to leave your ego on the shelf, and just get on with it?

  11. It all comes down to clarity. Concentrate on what you need to accomplish for the client, and forget about the rest. That's the only part that really matters anyway.

  12. Simeon says:

    "Agile Development" sounds like marketing speak for "Quick and Nasty" - like a high-speed production line, but for items that were typically rendered with high-quality in mind.

    It's a rapid growing trend (see Video Games and patches) that's gaining momentum because of the instant gratification that the end user gets. They get the product, to hell with the problems!

    I think it may have its place in design, but not always. I disagree that this method is useful 100% of the time, but I'm not going to say that it's completely bad.

  13. No, you're missing the point. This has nothing to do with "quick and nasty". It has everything to do with the order in which one invests time on a project.

    I'm not proposing that we ignore problems. Instead, I suggest that we don't waste too much time on things that we end-up discarding along the way.

  14. Kevin Cannon says:

    Interesting article & very prescient to what I'm learning at the moment. I recently went back to college to study a one year intense course in Interaction Design.

    We're learning a lot of about rapid prototyping, innovation & product design. One of the over-arching ideas is about 'Failing early and often' which is how companies like IDEO work. We generate a large amount of ideas very quickly, thrash those ideas out and then make quick mockups of the strongest concepts. Often these will be made of cardboard or paper and we test them with people to see how it address there core needs. As you've experienced, this makes you less attached to an idea and can find it a lot easier to throw it away later. It's been a fantastic learning experience for me coming from the web too.

    There's lots of books that talk about Interaction Design & Rapid Prototyping out there that might be useful if you're looking for further reading within a more design-related context.

  15. Simeon says:

    There's always going to be a degree of waste in a project which takes a lot of time, but is it all in vain?

    Could discarded ideas help add to the development of the final product? Could discarded ideas help in the development of future projects?

    (not trying to argue btw, just generating conversation)

  16. Pingback: eismann-sf » Reflections on Agile and Communication Design

  17. yann says:

    There was an article in A list Apart about agile design a week ago or so, you might want to check it out...

    Interesting article, as always, BUT... I can't believe you're going for the "no vowel" trend for your new website! It made me cringe when I read the URL... That alone makes me reluctant to click on it. Since I'm probably within your target market, hopefully, it's just me...

  18. I suppose that is a bit of a trend, and we certainly are as susceptible as anyone to those.

    This time, however, it was just a tongue-in-cheek sort of thing. I was looking at my keyboard several months ago and spotted a key named "undrln", short for underline. I liked it and registered the domain. And with this project it just seemed to fit. :-)

  19. This is a good idea. Reading it, I recalled a project I was involved with at a small studio I once worked at: Four designers spent literally hundreds of hours creating "perfect" comps for a poster, none of which hit the mark. The end client, noting the disconnect and realizing the number of hours being "wasted" said, hey, you could do pencil sketches of ideas and run them by me rather than investing hours to present this totally ready-for-the-printer concept! That led to a far better working relationship with that client, and the work was just as good if not better.

    I wonder if the rise of the computer to produce comps has generated a counter-productive expectation on the client end of picture-perfect concepts? Or if we as designers need to do a better job of managing client expectations at the concept stage, so we can go back to sketches and concepts expressed in words as a first step rather than, as Eric writes, doing all the sanding before the cutting?

  20. This is well thought out an obviously experimented with. I think the design process, even though it does have a formula, is a little different for everyone and some processes work better than other, however, you just have to find which process or mix of processes works best for you and your team to be most productive. Delivering a product is most important so however it is done, is the best way.

  21. Flo says:

    "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."

    You're right - many game studios have adopted this kind of behaviour. The results are games full of bugs and customers who feel like guinea pigs / beta testers.

    There is no excuse for getting apps / games / web sites out although they're not finished. Even when calling them "beta" (hail web2.0).

    No serious developer with his users in mind would ever do this.

  22. Oh Flo--comments like yours make me sigh.

    Ever thought about reading the entire post before commenting?

  23. Pingback: Design is all about Theory

  24. Agile development sounds worth exploring. The idea of making designs that 'work' first, as opposed to crafting brands to WOW the design community, seems like real synergy.

  25. Jason Graham says:

    Hi Eric,

    I really enjoy reading your blog. I would like to introduce this "Agile development for designers" to my company. Is there anywhere I can find more info on the subject? I checked the web briefly and all I found was alot of "agile software development." I would like to present this to them tomorrow!

    thanks for sharing

  26. Glad you like the blog--thanks!

    I don't know of many sites that reference applying this to design; however, I think a good place to start would be 37signals' book: http://gettingreal.37signals.com/

    Additionally, you might find more suggestions by going to http://www.undrln.com and asking the community to suggest links. :-)

  27. yael says:

    Very interesting. I had a discussion about this with a colleague at a respected design studio that does a lot of identity work. He described the process as you originally did, but maybe it differed a bit. Concept phase took two designers and one week to generate. They would generate about 200 logos like you mentioned. Thing is, they also presented about 4-6 finished logos in the end in a whole formal presentation. This is so different from the way I work. My process though allowed me to create good logos, but I spend way less time and charge far less for identity work. I think there is a happy medium. Do you really need to explore so far as doing hundreds of concepts? I think it may also depend on the client and how large and/or sophisticated they are. It's good to know differing processes for logo development, an area that I am evolving in. I think my process could use some revamping, but I deal with a lot of small companies so I am not sure if the 'all-out' approach (50 hours +/-) is something some of these smaller companies are comfortable with or able to afford.

  28. I'm of the mind that covering a lot of ground can be useful; however, I think it has to be done quickly. This allows for ample exploration, without "polishing" early.

    I am rather uneasy about the notion of presenting 4-6 logo options to a client. This is quite different from how we work, in part because we found it to be an unnecessarily arduous approach.

    From those 4-6 logos, the client now has to edit down to one, which generally results in them getting frustrated, surveying all of their friends, and ultimately "Frankensteining" a few of them into one final mess.

    Our approach now is to: research thoroughly, present findings, establish strategy, determine concept, explore and draft rapid samples, then refine. The bonus here is that it continually clarifies and refines the direction, instead of irritating the client by giving them many doors to open.

    It's easier. For the client and the designer. :-)

  29. Ben Yee says:

    Hey Eric, cool post utiilizing the same methodologies behind agile development.

    I think this model sits very well with the creation of application UI's. As you said it doesn't allow the designer to get caught up in the detail and let's them think about the overall goal of the design.

  30. Chris Browne says:

    Great post. Have you used/evaluated a tool to help you manage your projects? Check out Rally, we have a free version you can use to manage your projects.

    I've been very interested in taking an Agile approach to design and usability for a long time and it looks like things are starting to move in that direction.

  31. Impactomh says:

    Great Post!

  32. Kathleen says:

    Excellent post, Eric. It's nice to hear you are trying the agile methods as well. I find it encourages visualization early, as well as a highly collaborative environment, which we all know leads to innovation. I also find the concept of Perpetual Beta allows me to move past the preciousness of my work and try new things quickly. The challenge comes when you try to estimate a job, and knowing how long it will take to finish. Are you finding this aspect challenging too?

  33. For our core creative work, we simply estimate as we did in the past, and it seems to balance out in the end. (The hours just shuffle around a little.)

    On bigger development projects it's certainly tricky to estimate. That being said, we generally find this to be the case regardless of methodology given the nature of such projects.

    Sometimes we do alright and on others... Well, let's just say that we aren't going on any big holidays anytime soon. ;-)

  34. Great post, some really important messages in there. Keep up the goo work

  35. Mimi says:

    Hi Eric,

    In regards to your Dec. 16th post, I have a question for you. You mention showing more than 4-6 logo design comps to the client so they can hone in on the right direction. I agree this is the best way to get the overall design strategy set, but find sometimes this inflates the client's ego. They then feel entitled to art direct the execution, which may or may not be in the best interest of the project.

    My first thought is to give them what they ask for, as well as other better executions. Only problem is though, they are sometimes so in love with their idea they don't even look at the other designs. Any advice for how to politely keep execution in the designer's hands, so the client isn't running, and possibly ruining, the whole show?

  36. Actually, that's the opposite of what I propose. I feel it's the designer's responsibility to work through numerous options and edit them to the best one.

    In my mind, showing 4-6 options will only frustrate your clients. It's too much to assess; as a result, they'll end up “mushing” elements from all into one. This is almost certainly a complete disaster in the making.

    Work through a thorough strategic process to determine what they need to accomplish and how to do so. From there, focus on creating an effective overall system. Once you've done that, the logo/wordmark won't be a big sticking point.

    Your role as a designer isn't to make art or worry about whose ego (yours or your clients) is being massaged. It's to give your clients a solution that solves their problems. Concentrate on that and your customers will understand that they're dealing with a professional who's cognizant of the big picture and looking out for their best interests.

    You both share the same goal.

  37. Pingback: E-Commerce Blog By Solid Cactus

  38. Pingback: Can a Marketing Agency Be Agile? (Inside Forty)

  39. Pingback: UX & Agile Articles » agilemusings.com

  40. Pingback: Can a marketing agency be Agile? | Forty

  41. Pingback: Agile design: what we've learned - Forty

Voice Your Opinion

Thoughtful and critical comments are welcomed, and we ask that you use your real name (just seems fair, doesn't it?). Offensive, derogatory, and dim-witted remarks will be removed or result in equally mean-spirited finger-pointing and mockery.

Required

Not published