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: Effectiveness of a document? From:"Christensen, Kent" <lkchris -at- sandia -dot- gov> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 27 Feb 2002 07:46:14 -0700
re: Rohini Gogi wonders: <<I need your inputs on how you would measure the
effectiveness of a document against a set of parameters. What are the
parameters that would kind of certify a document?>>
Some random ideas ...
If your process is tightly controlled (people in your company use the
document to perform company work, for example) you can likely measure
performance error rates.
Whether tightly controlled or whether your document is just used by external
customers beyond your control, you can certainly analyze calls to your tech
support.
In any event, an ideal situation is to develop the ability to "test" your
document prior to publishing it in its (first) final form. Gather some
"guinea pigs" and have them perform the work using your document and observe
and improve your document as indicated. Many times you cannot 100% solve
problems that are discovered, and this certainly provides parameters for
further measurement and for product design improvement in the long run.
Many assume this too expensive, but the relevant cliches are
pay me now or pay me later
we don't have time to do it right, but we have time to do it over
Suggest concluding that you are testing your "product" and not just the
documentation. See the documentation as part of the whole, and yourself as
part of the product team. Sometimes it's the hardware/software that needs
fixing and not the documentation. Sometimes your product developers can
help you when you all work as a team. Your customer surely sees the
documentation as not separate from the whole product--you should, too.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now's a great time to buy RoboHelp! You'll get SnagIt screen capture
software and a $200 onsite training voucher FREE when you buy RoboHelp
Office or RoboHelp Enterprise. Hurry, this offer expires February 28, 2002. www.ehelp.com/techwr
---
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.
