RE: Making them read the documentation

["Giordano, Connie" <Connie -dot- Giordano -at- FMR -dot- COM>]

Steve, 

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.

MTC
Connie Giordano


-----Original Message-----
From: SteveFJong -at- aol -dot- com [mailto:SteveFJong -at- aol -dot- com]
Sent: Thursday, April 26, 2001 2:16 PM
To: TECHWR-L
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
consider 
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
the 
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
licenses 
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
them 
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 http://www.devahelp.com 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. http://www.pdfconference.com. 

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