Re: Post-holiday reality: They don't need our stinkin' manuals??

Subject: Re: Post-holiday reality: They don't need our stinkin' manuals??
From: "Chuck Martin" <twriter -at- mindspring -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 27 Dec 2000 17:20:47 -0800

"Cook, Jenise" <jenise -dot- cook-crabbe -at- pacificlife -dot- com> wrote in message
news:83975 -at- techwr-l -dot- -dot- -dot-
<snip>?
> Is that what our jobs are all about, writing manuals that many users do
not
> read? I asked myself that question that evening. I decided that no matter
> how the users out there may or may not use the documentation we write,
some
> users definitely will. Those are the users I write for, and think of
during
> the planning phase.
<snip>

It sounds like your family members, as with many users of hardware and
software (and ballots), bring their expectations and experience to the
handling of a new object and try to use it based on those expectations and
experiences. This is why technical communicators do so much more than write
manuals.

In a recent local newspaper review of 3 digital cameras, ease-of-use (or
lack thereof) was not given short shrift, and the ability of the
user/reviewer to understand the camera's basic functionality from the
camera's design was a significant factor in the final rating.

Everything on that new camera, the size, shape, and placement of controls,
the controls that existed (and didn't exist), the labels, and so on,
communicated information to your family members. Whether what was
communicated was useful or not seems to have been decided by the people who
could not figure out how to do the basic functions (adding batteries
properly, reviewing taken pictures). The solution in most cases isn't to
have them read the manual, but to produce a better-designed product.

See Donald A. Norman's book "The Design of Everyday Things" for lots of
examples of regular people who have trouble with common objects that were
not designed well (and often need extra documentation to try and overcome
that bad design).

Technical communicators who learn about and understand design, cognitive
psychology, and related areas not only write the documentation, but involve
themselves in the product design process, showing that better design makes
for happier customers, better (and easier to write) documentation, fewer
support calls, and higher sales.


I'm baaaack....

Chuck Martin
now at (for now) WetFeet.com
twriter -at- mindspring -dot- com



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by an
anonymous satisfied subscriber since 1994.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit
http://www.raycomm.com/techwhirl/ for more resources and info.


Previous by Author: RE: Momentarily press and then release?
Next by Author: Lead time between code freeze and release
Previous by Thread: RE: Post-holiday reality: They don't need our stinkin' manuals??
Next by Thread: Re: Post-holiday reality: They don't need our stinkin' manuals??


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


Sponsored Ads