Re: Documentation not as important anymore?

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

This is in response to Anatole's posting on the importance of documentation vs
ease-of-use and other features of software:

****************************
Contents of the quoted survey:

" Looking back further into industry history, Walsh observed that, ten years
ago, documentation was the most important feature to software buyers. Today,
though, corporate concern over documentation is far outweighed by interest in
support, with 72 percent of respondents rating support, service and training as
"very important," and only 47 percent doing so for documentation.

Ease-of-use, the number one feature last year, with "very important" ratings
from 66 percent of survey participants, is slightly behind support this year
with a 71 percent score. "
****************************

Remember these studies, by their very nature, tend to focus on the
differentiators among products, not the absolute level of quality or importance.

For example, I would bet that ten years ago, "true IBM compatibility" would have
been listed as a "very important" attribute of PC hardware, since there were
bunches of "almost-compatibles" on the market (anybody remember the infamous
Tandy 1000, or the TI machine?).  Just getting a "compatible" to run your
software was a real trick.  Today, being able to run "IBM compatible" software
is assumed and nobody worries about it; interest drops to zero.

*****************************
The obvious conclusions are that the customers don't really understand what they
need (if they read the manuals they wouldn't need so much support), and that
they're obviously not making the connection between good documentation and
ease-of-use.
******************************

Of course they understand what they need; they're customers.  They want stuff
that works and when it doesn't work, they want it explained in the easiest
possible way; the easiest way varies by individual.

It's entirely possible that most of the document readers are happy (and thus
silent) while the support-oriented folks are exasperated by playing "chucklehead
roulette." (A friend's name for some company's apparent policy of staffing one
smart, competent support person per six phone lines; a given call has a five out
of six chance of hitting a dud.)

*****************************
So what do we do, as technical communicators, to get customers to make these
connections? A manager or exec reading this study might conclude their money is
better spent on a couple of people answering service calls rather than on
writers, designers, online help-building software, and printing costs.
*******************************

Granted, keeping management from doing something dumb is almost a full-time
job.  (Of course, keeping *us* from doing something dumb *is* manangement's
full-time job.) ANYWAY, I think we make some of the points I've outlined above
and then rely on inertia.

Ove the long run, as I've noted before in some job-hunt related postings, I
don't think that "technical communicator" is going to survive as a discrete area
of expertise.  Rather, we software folk are going to find ourselves
increasingly lumped together in a single group that spans much of what is now
covered by business analysis, system analysis, interface design, documentation,
and training.  Before your eyes glaze over, bear in mind that there will be
some truly awe-inspiring authoring tools to help.  Meanwhile, developers and
analysts will have to get more business-centric, business users will have to
get more technical, and *everybody* will have to learn to communicate.

Doug
ENGSTROMDD -at- phibred -dot- com