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.
Mickey Platko wondered: <<My team believes high quality, well-written
support documents increases the ability of customers to solve their
own problems, rather than calling the help desk. We're looking for
articles or studies that indicate that quality documentation reduces
costs and increases customer satisfaction. Can anyone point me in the
right direction?>>
A 1995 special issue of STC's journal _Technical Communication_ (on
value-added, with Ginny Redish as the editor) provides a good range
of articles that prove quite clearly how we add value--and by how
much. You may also find something of interest in the following
article, which is by no means equally rigorous, but nonetheless
provides some food for thought:
http://www.geoff-hart.com/resources/2001/worth.htm
Unfortunately, although the basic premise is sound, there are several
problems with the effort to prove that we add value. First, people
who read neither manuals nor online help will not benefit from well-
written documentation. This means that your documentation will only
affect the (potentially small) subset of your audience that actually
reads this material. Worse yet, if you're in the situation of trying
to fix substandard or even bad existing documentation, this
proportion becomes even smaller, because people who have learned not
to trust your docs won't keep trying to do so. <g>
Second, the best documentation in the world can't save a crappy user
interface, poorly debugged software, or a product that simply doesn't
work the way its users work. So you can't solve these problems
through documentation. However, since we're often the first people to
see a product, we are also the first ones to spot these kinds of
problems. If we can report the problems and provide a suggestion on
how to fix them, we clearly add value to the process--but that value
is difficult to quantify, because if you solve a problem before any
user encounters it, you can't easily collect statistics on the impact
of that problem.
On rare occasions, we get to actually kibitz over the interface. I've
occasionally had an opportunity to sit down with the programmers and
discuss how a program should work, and demonstrate this*. Value
added? The programmers design the interface once, then start coding,
instead of constantly tweaking and revising the interface, wasting
many hours in so doing. I've heard of a few companies who actually
understand the value of this up-front design. Their numbers are
growing, but they're still desperately in the minority.
*Hart, G. 2006. Creating interactive prototypes: let's move beyond
"paper prototypes". Information Design and Architecture SIG
newsletter (http://www.stcsig.org/id/id_articles/
0601_interactive_prototypes.htm) --> The link is broken, but you can
probably find it there (June issue, I believe) with a bit of poking
around. Just getting set to leave on a trip, so I probably won't have
time to post my version of the article on my own Web site. Later this
year, hopefully!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
