RE: Don Norman on Manual Writing

["Nuckols, Kenneth M" <Kenneth -dot- Nuckols -at- mybrighthouse -dot- com>]

Jens Reineking said:
> 
> How To Write an Effective Manual
> by Don Norman
> 
> http://www.jnd.org/dn.mss/how_to_write_an_effe.html
> 
> 
> Practical suggestion? Unreachable utopia?
> 
> What's your opinion?
> 
> 
> Jens
> 

A little of both. 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.

2) "The manual should be activity-centered. Pick the most basic
activities and explain how to accomplish tem. Make the explanations
short and simple, with illustrations... Remember: people do not want to
read manuals -- they want to do their activity. Let them get right to
work, with minimum reading." -- Again a good idea. Tell the user HOW to
accomplish something first. Then, if it's appropriate for the audience
(depending on the type of product or the class of user for whom the
particular manual is written) provide more detailed exposition and
explanation. Keeping the "operational" portion of the manual
task-focused will allow the user to more rapidly and easily find the
information necessary to use the product.

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

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. 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.

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.

3) "Get rid of the lawyers, or at the least, put their required warnings
in a separate booklet or Appendix. When a manual is needed, it is needed
right away, and having to work one's way through umpteen pages of legal
warnings (that are behaviorally ineffective) only increases the anxiety
level and decreases the pleasure of the product." -- 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.

For what it's worth, that's my take on the site.

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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! http://www.webworks.com/techwr-l

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. http://www.componentone.com/TECHWRL/DocToHelp2005

---
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 http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com

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
http://www.techwr-l.com/techwhirl/ for more resources and info.