We have met the enemy, and it is first-draft design

Excellent commentary by Nancy Duarte on the recent NYT article. (A more readable version of the original alarming graphic is also available.)

A few things about the graphic:

1) This is an example of a diagram that was probably developed by analysts to help them understand something. Think brainstorming. The presentation mistake here (aside from the general bullet bullet bullet approach) was trying to use the same diagram to explain things to people who were most likely not part of the original discussion. Of course it stinks for that purpose. To build on Nancy’s commentary on our first-draft culture, it’s easy to imagine the excited consultants transposing this diagram from a whiteboard into PP, then – confusing the effort that went into drawing it with its value – it subsequently showing up in every PP deck that discussed the topic for the next year. What appears to be missing was the second (or third) iteration: translating the understanding into a diagram that explains the important points.

2) As a consultant, and not knowing the full story, I am disappointed and embarrassed that this diagram ever made it out of the working group and onto the screen of a client. On the surface this seems like a pretty serious delivery failure. In my own experience I have often seen (and created) some pretty confusing diagrams and models in the course of trying to understand a complex problem or system. But those things usually end their life on a white board or as a scan, they rarely survive in their original form as a deliverable because they were never intended to be such. The final deliverable often bears no resemblance to the original because after we think we understand an issue, the focus changes to explaining it. And those questions are different (see Dan Roam), so the results are usually different. I have referred to this as iterative design but for it to work, you have to actually do the next iteration.

So the moral of the story is: do the second iteration, your audience will thank you.

Intentional smudge

I used to know an illustrator who described how he would add a smudge to some inconsequential area of an illustration because he knew art directors (his clients) would always want to change something, so he gave them a target. I called this the intentional smudge and have discussed it with clients and used it myself from time to time.

I was amused to see Seth’s latest post discuss the same basic principle.

Both are good ways to help keep important ideas intact through the rigors of most approval processes. Of course, that assumes the stuff is worth keeping.

Getting it right versus getting it perfect

I’m a big fan of iterative design – getting something out there quickly and refining it along the way. I also recognize the limitations and dangers of this approach:

Too little planning. Rushing to get something out doesn’t release you from thinking about what you’re really doing. Lots of bad presentations happen this way – in a rush to get it done, no one seems to remember why or what they’re actually doing (audience, messages, etc).

No additional iterations. Just because you’ve hit the first milestone doesn’t mean the product is good or even halfway evolved. You can’t stop at the first draft, you have to actually keep developing to take advantage of the value if the approach. Usually fairly quickly (sometimes hours, not days or weeks).

Ego. To take advantage of a group’s collective insight (no matter how small the group), one must set one’s ego aside and really listen to comments and suggestions, adopting the ones that best serve the projects’ objectives. Not so easy.

But maybe the biggest challenge of iterative design is getting started – just doing it. There seems to be a basic human apprehension (at least among some of us) to put something out there if it’s not absolutely perfect. Of course, sometimes this is a good thing – I don’t want to use a bridge that was built off a napkin sketch – but often (especially within small teams) getting the first cut out quickly for some live feedback has real advantages. And if (or when) things change, then they change. No big deal. (As long as everyone knows that they may be looking at a work-in-progress.) Feedback from real users (the audience, customers, clients, etc.) has a great way of quickly focusing attention on what really matters.