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: Value added by technical documentation From:John Bell <jbell -at- PARAGREN -dot- COM> Date:Fri, 7 Mar 1997 15:45:43 -0500
Paul Branchaud[SMTP:paul -at- VEDGE -dot- COM] wrote:
The best sign
that you have provided customers with good documentation (IMHO) is if the
technical support lines are quiet. Although I have no proof, I feel there
is a direct correlation between the quality of documentation and the
number of calls a technical support line gets with regards to a specific
product.
==========
I have heard it said that the goal of good documentation is to eliminate the need
for technical support. The goal of good user interface design is to eliminate the
need for documentation.
One project produced by a former employer was so poorly designed that the writer
I assigned to the project was overstressed. The manual ended up being 4-5 times
bigger than it should have been if the UI had been designed properly. The support
effort needed on that product was way out of line compared to our other products.
Because we did not have proper cost accounting, the offending product manager
ended up looking very good. He produced his behemoth under budget, but he ended
up blowing my budget and the budget in the tech support department. If we had a
separate testing department at that time, he would have blown that budget too.
Management eventually caught on to the relationship between design and support costs
and we had to retroactively compute the true costs of all projects in the two years. When
we did that, that manager looked very bad. He was eventually fired, but for a far
different reason.
A good manual (or online help) usually draws no
attention to itself (good or bad), it just does its job of informing the
user.
=========
This is generally called "transparent". Transparent writing is a goal that is rarely
reached. It certainly is one of my goals!
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
