Ready, Fire, Aim

It's not what you think, I'm actually in favor of that sequence as a development strategy.

At its core, it's the heart of Agile development, rapid prototyping, and all kinds of good things that get people engaged.

There's an old technical writer joke (i.e., a joke told by an old technical writer).

Instructions for getting unlost in the woods:

1. Pack a user guide with a typo in it.
2. Pack two loaves of bread and some cold cuts.
3. Sit and wait for the dozens of people who will find you to tell you about the typo. (The bread and cold cuts are so you can have sandwiches for them when they come calling.)

The point is that people don't get very engaged over abstract ideas or plans, but put some kind of a design stake in the ground and man do they come alive! In short, give them something to criticize or disagree with as early as possible, then make the sandwiches and wait for the crowd.

A problem we have as traditional technical communicators (designers all around probably) is that we are reluctant to show early designs that we know aren't very good. We all want to clean the house before the housekeeper shows up.

I was at the UA Europe conference in Cardiff earlier this month, and one of the presenters, Leisa Reichelt, talked about her experience getting the Drupal.org community actively involved in redesigning their web site. One challenge she had to overcome was her own discomfort at posting "the worst wire frames I had ever done," as early design concepts. But she did it to get early feedback and involvement--and it worked.

Some pointers:

• Don't be afraid to show preliminary work early
• Don't over design--early documents, for example, can have just bullet points capturing the key talking points the topic will address
• Use low-fidelity prototyping tools. If it looks like it was drawn on a napkin, people are less inclined to criticize its lack of polish and more inclined to comment on the essense of the design's objective (check out Balsamiq Mockup).
  
• Use collaboration tools like Wikis. Then if someone points out a typo, quickly answer, "Oh, it's a Wiki, you can correct that any time you like."
• Respond quickly and incorporate suggestions.

These pointers work for all aspects of design: UI, user assistance, and even project plans.

Note: You can substitute pizza for the bread and cold cuts.