Wednesday, September 30, 2009

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.

2 comments:

Paul Griffiths said...

This is OT, except that you mention the UA Europe 2009 conference in Cardiff and I can’t find another way to ask my question.

In your excellent presentation in Cardiff on a phased documentation strategy that mirrors the adoption process, you had a close-to-final slide labeled “Single Release – Consumer-level user.” My attention must have wandered for a moment, and I’m afraid I missed the point you were making here. Could you explain?

Michael Hughes said...

The problem, Paul, is that the slide's point was made in colors that did not contrast well when printed in black and white. The presenter should have consulted an information design special...oops.

The point is that when you only have a single release opportunity to get out your user assistance, and if the product is primarily aimed at non-techies, then the important elements to get into that release are the following:

* Social networks
* Inline UA text
* Help panels
* Hover text<
* Inline instructions and examples
* Task-level topics
* Conceptual topics