RE: Making them read the documentation

Subject: RE: Making them read the documentation
From: "Dan Brinegar" <vr2link -at- vr2link -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 26 Apr 2001 05:55:54 -0700


Hmmm...

Does the product need work? Does the manual need work? Do the pointy-hairs
realize how much of their valuable engineer-time is being taken up with
techsupport? Was killing off the help desk in a cost-cutting move *really*
a good idea?

;-D

These questions may or may-not apply to your current situation. YMMV.

I'd recommend the following whether you're writing a new book or trying to
find out which internal users aren't reading which manual (and chewing up
all the engineers' time); go to the jobsite with one internal user and,
WITHOUT your manual, attempt to perform the required tasks. Next day, go
with another internal user and do the same thing, but look it up in your
manual whenever y'all have a question (you wrote it, you'll know where to
look).

Find out what the users DO to accomplish the job: is the manual organized
along the same lines? Do they have to jump from chapter to chapter to find
the answer during one step of the procedure? Does the manual *say* where
else to look if ya need more info?

I'm usually the kind of guy who'll want to play with the product and break
it at least once before reading about it: if the product's NOT available to
play with, I'm highly reluctant to go to press with only what an engineer
has told me about the product... [whattya mean those rants are too old to
show up in the TECHWR-L archives anymore?]

I've found that if I need an engineer to sit with me all day and hold my
hand while I figure out what the user needs to do to make the thing work
before I can write it down, then the *product* needs work-- in most
instances, however, before the engineers realize their product is really
hosed they're running off to fight fires and so can't give me their
undivided attention for too many days... of course if this is the way
things have always been done there, bringing the problem to the attention
of the pointy-hairs may just splash back on you.

On Wed, 25 Apr 2001 <michelle -dot- black -at- sickkids -dot- ca> wrote;

>--my experience
>with both documentation and education is that involving the users in the
>planning, even through something as simple as a questionnaire or short
>interview, gets them more on side with your project because they feel their
>needs are being considered. And, you often get invaluable suggestions,
>insights
>into their context

-------------------------------------------------------------
Dan Brinegar Information Developer/Research Droid
(Retired)

"Leveraging Institutional Memory through Contextual
Digital Asymptotic Approximations of Application Processes
suited to utilization by Information-Constrained,
Self-Actualizing Non-Technologists."

vr2link -at- vr2link -dot- com CCDB Vr2Link
http://www.vr2link.com Performance S u p p o r t Svcs.



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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


Follow-Ups:

Previous by Author: RE: American English to British English
Next by Author: Re: Whaddaya know? (long)
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