Re: Are manuals and ...

[Bonni Graham <bonnig -at- AOL -dot- COM>]

Doug hits the nail on the head.

Why don't people read accompanying manuals (as opposed to 3rd-party ones)?
Because we (the computer industry) have taught them that these manuals don't
have the information they need.  Writers of these manuals have, by and large,
no customer contact (except, in very fortunate cases, indirectly via tech
support).  We're (writers) not given enough time to do the job right, because
there's this perception that as soon as the golden disks are ready, the
product is ready to ship, and that every day after that date is a "delay".
There's also a perception that the writer should not start to work on the
program's manual until, say, beta testing.

And some of it is because the industry is full of "dorks", otherwise defined
as people who absorb this kind of information via some weird brain-osmosis,
and think that anyone else who doesn't obviously isn't smart enough to use
the program anyway.

It's not just computers.  Raise your hands if your VCR is still blinking
12:00.  Come on, I know you're out there.

There are a couple of pragmatic things we ourselves can do to fix it, at
least in the computer industry:

1) If you can get your hands on tech support's call log, flag all the calls
containing questions that could/should have been answered in the doc.  Take
this list to your supervisor (or, more effectively, tech support's).  Make it
clear to this person that you can DEFINITELY raise first-call statistics by
including this information in the manual (and PLEASE be sure to index it when
you do...) and teaching tech support to guide people to the manual.  The more
we doc to the question, the better a manual we'll have.  But we can't know
what the questions are unless we have help from tech support.

2) If you work for a company that produces a product that has 3rd party books
out there, point out to marketing/sales/the CFO that that book is generating
dollars that could be going in YOUR company's pocket, if only you had the
time to produce the books properly.  For example, the product could include,
free of charge, a basic reference guide.  BUT, you could sell a tutorial --
if people will spend the money at a bookstore, they'll spend it with you, if
you market it properly.  Money does, indeed, talk.

I'd love to hear other people's ideas on this -- marketing Tech Pubs/Info
Development services both within your company and to contracting clients.
Like people who sell financial planning, we don't have to invent a need for
our services -- the need is there already.  We have to invent effective ways
of demonstrating that need.

Thoughts?

Bonni Graham
Contractor/Information Developer
President, San Diego STC
BonniG -at- aol -dot- com