Don Norman on Manual Writing?

Subject: Don Norman on Manual Writing?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "Nuckols, Kenneth M" <Kenneth -dot- Nuckols -at- mybrighthouse -dot- com>, TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 27 Dec 2005 11:08:01 -0500

Ken Nuckols observed (in the context of Don Norman's article,

<< Some of his ideas are spot-on and any company would be well-served to implement them. A couple stand out: 1) "The Manual Writers should be a part of the design team." -- Having the writers involved early can provide designers and engineers with some good feedback on both usability and "product" function.>>

It also produces a team environment in which cooperation and learning from "the other side" occur. I've worked with programmers to help them design or redesign an interface and create effective labels for the parts of the interface so they could concentrate on the plumbing. They found this easier and more efficient than producing a dozen drafts of the interface, and were duly grateful. Of course, then I had some issues with the program manager and that ended _that_ brief but happy experiment....

<<2) "The manual should be activity-centered. Pick the most basic activities and explain how to accomplish tem.>>

Alan Cooper has written at some length about this concept, but from the perspective of "personas". Very interesting work, and I'm currently trying to adapt it into a presentation I'll be giving to STC Montreal in March. Cooper has considerable street cred because he's both a respected programmer and a sought-after design consultant who has a record of simply making things work. Moreover, he picks up on some of Norman's early work (the wonderful _Psychology of Everyday Things_) to design products that work the way people want them to work rather than forcing people to change how they work.

<<However, some of Nelson's suggestions fall into the "utopian" or "fantasy" realm, IMO:>>

"A man's reach should exceed his grasp; else what's a heaven for."--Robert Browning. We achieve utopia by striving for it, conscious all the while that we may never attain that goal. It's the striving that makes things better. In that context, allow me to play devil's advocate for a moment:

<<1) "Ideally, the manual is written first, aimed at being short, simple, and understandable. The designers and engineers help oversee the writing, for when the manual is complete, it will serve as the product specifications that they will follow. Therefore, they must buy into the design from the beginning." -- This is impractical and unrealistic.>>

Actually, it's neither. Architects build houses in precisely this way, and the software/hardware design business would be more effective and much less prone to error if it adopted an architectual design model. Instead, the current process is more like the following: "Let's build a house. With three bedrooms. No, two. No, four. No... two bedrooms and two office spaces with folding cots. No, forget about the cots... let's go with Murphy beds. Yeah! And let's use Sealy mattresses. No, how about tempurpedic foam? Yeah! No, wait... how about water beds? _Murphy_ water beds! OK, let's tear out the walls and install plumbing so there's no messy garden-hose business each time we need to drain the bed. Hey... we could install a drain in the bottom of the bed and use it the water for emergency fire suppression! (We'd automate that of course, since we can't leave the decision to the user. So what if there are occasional accidents?) And if we recirculate the water, we can do heat-recovery in the house!"

Yeah, that'll work. Never mind that they forgot the bathrooms, never bothered asking how many people will live in the house, and never considered usability requirements such as separating the master bedroom from the rooms for the kids to give both the adults and the kids some space and privacy.

<<The next time a team of designers, developers, and engineers winds up completing a project EXACTLY as it was designed, conceived, and envisioned without any additions, deletions, or changes will be the FIRST time that has ever happened in the history of product development, dating from the invention of the torch (fire on a stick) to the present microsecond.>>

Though I have some sympathy for this notion, the main reason that software projects fail more often than they succeed is precisely because managers have bought into the notion that it's impossible to know what you're designing for when you start. Moreover, they believe that products are sold based on features, not usability, and that the more features we build into each release, the happier users will be. Both opinions are a load of crap. Design for discrete targets and you'll hit them; design for a constantly shifting target defined by the cool idea of the day and you get the current chaos: unusable, bug-filled products that ship late and require dozens of patches.

It's not hard to figure out a core batch of features and design so that version 1 supports those features elegantly and effectively. If you know that there will be two additional core sets of features that are not essential, but that will certainly be useful at some future point, you design version 1 to allow those features to be added... just as the architect can leave room to add a wing to a house if they know that this is part of the user's eventual goals. The hard part is disciplining yourself to accept that core set of features, and put off the cool but nonessential stuff for a future release.

<<2) "Test the manual with people chosen to match the intended user community. How do you test a manual before the product is even designed? The manual testing should be done in conjunction with the first design tests, using the rapid-prototyping techniques used by the your Human-Centered Design team. They don't do rapid, frequent prototypes? You have a bad team--change it." -- Again, this is pure fantasy. You can't test something before you have a prototype, and you can't have a
prototype until you get a design agreed upon; and the minute you allow users to be part of the process there will be changes because everyone will have neglected to think of something the end user wants or needs.>>

Cooper's work shows exactly the opposite. It's trivially easy to create a rapid prototype once you've built a design spec. Indeed, I've got an article on how to do this with inexpensive tools (Powerpoint and Dreamweaver being two) coming out in January from STC's Information Design SIG. The goal of working with users is to find out whether you've guessed right and met their needs with the prototype. If that proves to be wrong, you adjust the prototype until it meets those core needs. You don't start building anything before you know what you're building.

<<3) "Get rid of the lawyers, or at the least, put their required warnings in a separate booklet or Appendix..." This will never
happen because of the need for companies to protect themselves from liability. As stupid as it may seem, if you neglect to put the warning that one shouldn't use a hair dryer in the bathtub in the main manual, in a conspicuous label on the product, and on the packaging, those same lawyers you fired will escort that one idiot client who thought drying his/her hair in the shower was a good idea to court against your company and will probably win.>>

Norman's early work provided an elegant discussion of how to design for error and failure. Understanding how things will be used, and the fact that "to err is human", means that you can design to eliminate obvious failures or make failures "inexpensive" when they do happen.

For example, why not build an effective ground-fault interrupter into that hair dryer so it's impossible to electrocute yourself? Why not build takeout coffee cups with simple swinging valves that seal when the cup tips? Why not automatically save a copy of all deleted files for 2 weeks and offer a "recover old files" option directly in the software's user interface? Because that requires us to think about how people would use the product, and apparently that's more work than hiring a fleet of lawyers to protect us.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today!

Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author content and configure Help in MS Word or any HTML editor. No proprietary editor! *August release.

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
To unsubscribe send a blank email to techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

RE: Don Norman on Manual Writing: From: Nuckols, Kenneth M

Previous by Author: Word "Find and Replace"?
Next by Author: Documentation review?
Previous by Thread: Re: Don Norman on Manual Writing
Next by Thread: RE: Don Norman on Manual Writing

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads