RE: Making them read the documentation

Subject: RE: Making them read the documentation
From: "Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 26 Apr 2001 14:30:31 -0400


As good as your suggestions are (and they are excellent for the
documentation portion of the cycle), they don't fully address the problem.
Simply put, good documentation can't fix bad design.
My goal is not to produce documentation that reduces support calls, it's to
contribute to designing a product that users will accept, can learn, and
benefit from. Sometimes that means accessible pdf docs or MS Word files,
sometimes it means on-line help, or whiz-bang tutorials. And sometimes it
means going back to work with the engineers and the business analysts to
determine if an infrequent task needs to be done in a wizard, or if a window
needs to be reorganized and relabeled.

We are not a kingdom unto ourselves. And as long as we continue to think of
ourselves as separate from engineering, QA, or tech support, we will
continue to be viewed as extraneous overhead, and we'll continue to get
about 13 hours to write 400 page manuals that nobody ever reads for products
that everyone complains about.

Connie Giordano

-----Original Message-----
From: SteveFJong -at- aol -dot- com [mailto:SteveFJong -at- aol -dot- com]
Sent: Thursday, April 26, 2001 2:16 PM
Subject: RE: Making them read the documentation

Lately I have been thinking about this important issue just raised by S
Godfrey [mailto:kittenbreath -at- lycos -dot- com] -dot-

I agree with Jane Carnall <jane -dot- carnall -at- digitalbridges -dot- com> that we as a
class are poor user models because we like to read documentation. (I
people who refuse as people I hold a significant competitive advantage over.

They're the ones who start out saying "I never read manuals" and end up
looking over my shoulder saying "I didn't know it did that!") But we must
consider our audience, not ourselves 8^)

Tasks can be classified according to frequency of repetition. Common,
everyday tasks, while they need to be documented and trained on, won't be
read about. To use Microsoft Word as a common base of experience, no one
needs to read the manual for a refresher on opening a file, inserting text,
and saving the change.

On the other hand, uncommon tasks usually aren't included in training, but
should be in the documentation, and need to be read up on. How many people
know how in Word to change the color of revised text? It's an uncommon task.

The installers may think they're doing everyday tasks and thus don't need
manuals; the problem is that by inspection it's obvious they're wrong
(because they're calling to ask questions). Surveys consistently show that
people are more comfortable asking colleagues for help than calling Tech
Support or reading manuals.

Access to the documentation can be a problem. You may have Word on your
system, but do you have the Word manual? Lots of companies have site
for Office, but only one copy of the manuals. Do your manuals actually get
into the hands of your customers? Ours sometimes don't, and that's a problem

too. But we've noticed that our users aren't even fully aware that we have
Help files, so PDF isn't the answer 8^(

Our goal should be to provide documentation that can reduce the number of
support calls. (I know that bucks the polls, but as my colleague says,
manuals don't draw a salary 8^) I endorse the idea of asking Tech Support to

make a show of looking up the answer in the manual for the customer, even if

you offer free support. I also suggest that you try to get feedback from
on what questions *aren't* answered by the manual.

-- Steve


*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at or info -at- devahelp -dot- com

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 Conference East,
June 4-6, Baltimore, MD. Now covering Acrobat 5. Early registration deadline
April 27.

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 for more resources and info.


Previous by Author: RE: Making them read the documentation
Next by Author: RE: Is IT growth slowing?
Previous by Thread: RE: Making them read the documentation
Next by Thread: RE: Making them read the documentation

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

Sponsored Ads