My friend Kathy Sierra is doing a world tour this spring and summer: New Zealand for Webstock, Spain for a Gnome conference, and more. She's cramming in lots of good blogging, in spite of all the travel, including this one reminding us what good design is really all about.
Kathy's post resonated for many reasons. I'd just written an article about how OpenOffice toolbars are really configurable, so IT folks can make the interface as easy and usable as possible for their users migrating from Microsoft Office. Don't want them to use something? Take it off the toolbar! Want them to use three things? Make a menu called Import and put those three things on it. It's far more effective than sending out long emails describing what the new procedures are.
The other reason is that I've worked for many years as a techwriter before leaning more into the training and books arena. You can't get away completely from documentation in all products, of course--just take a look at the huge numbers of volumes of Oracle docs, for instance. But so often, products are written about, instead of being designed well.
We called it the "documentation band-aid." Why is there a big CAUTION on every other page? Because there aren't any safeguards in the software to keep you from doing that thing. Why is there an enormous glossary and reference guide? The prompts aren't clear, or there are either A) five words for the same thing or B) the same word is used to describe five different things. Why aren't there always just a bunch of wizards under a nice Tasks menu to pop up the windows you need and highlight the relevant fields, one by one, if you wanted help? That would be grrreat.
I'm not cussin' out software designers or making excuses for poor techwriters. Just pointing out that writing everything down is the wrong way to do it and way too late in the process. Don't treat the symptom; prevent the disease. Don't describe how you're supposed to do it; make the right way the obvious/only way.
How to do it? Maybe assign the techwriters halftime to the design meetings--and listen to what they say. (Why would busy developers let techwriters or other design- and procedure-oriented folks into the design process? For one thing, we won't be bugging you to review huge manuals a week before release. ;> ) I imagine test-driven development wouldn't hurt either, though I'm a little bit out of my depth at this point.
I know that thinking of all the mistakes that a user could make is time-consuming and complex. But so is writing documentation, answering support calls, trouble-shooting, and all the other stuff that comes from design that people don't get.
Of course, the ergonomic way is the better !
Do you know the comics OK/Cancel ?
http://www.ok-cancel.com/
New strip each week, and articles about design, user experience, etc.
Posted by: Sarah Haim-Lubczanski | May 24, 2006 at 09:30 AM