TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: Making them read the documentation From:SteveFJong -at- aol -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 26 Apr 2001 14:16:27 EDT
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
Steven Jong, Documentation Team Manager ("Typo? What tpyo?")
Lightbridge, Inc., 67 S. Bedford St., Burlington, MA 01803 USA
mailto:Jong -at- lightbridge -dot- com -dot- nospam 781.359.4902[V], 781.359.4500[F]
*** 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.
