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: Field testing manuals From:Rick Lippincott <rjl6955 -at- gmail -dot- com> To:"Bruce Megan (ST-CO/MKP3.2)" <Megan -dot- Bruce -at- us -dot- bosch -dot- com> Date:Fri, 11 Sep 2015 06:11:09 -0400
If you do have an opportunity to do some field testing (or find a
customer willing to give it a go), it helps if you've got a plan and a
structure.
For example, classify tasks as to how they can be validated:
* Demonstration - someone will walk through the procedure by reading a
step, doing the step, reading the next step, doing the next
step...etc...and recording any issues.
* Simulation - used when actually performing the procedure could cause
a disruption. Same process, but it's more of a visual check of the
docs against the system.
* Desktop Comparison - bump the docs against the system by checking
the engineering data.
Which method is appropriate for a given task is a matter of
circumstances, and any given doc will likely include all three
methods.
The next thing you may want to consider is to start building a rating
system so that you can track the quality improvement. Tally the number
of errors against the number of pages. More importantly, classify the
errors according to seriousness, rate them on a scale. For example:
Defect level 5: This error could lead to death or injury, or damage to
the system.
Defect level 4: This error will cause the system to stop, and the user
will not be able to recover without assistance.
Defect level 3: This error will cause the system to stop, but the user
will probably be able to figure out a recovery method.
Defect level 2: This is an error that the user will almost certainly
be able to figure out.
Defect level 1: Typos, spelling, grammar, and other items that don't
affect meaning.
Defect level 0: It's actually correct as written, but here's a
suggestion on how to make it easier to understand.
This usually works best when someone is tasked to do a complete review
of the doc, as opposed to hoping people will remember to write down
things as they find them.
I've done this in a couple of places, and the resulting quality
improvement to the docs can be significant.
--Rick Lippincott
"I Explain Things"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn more about Adobe Technical Communication Suite (2015 Release) | http://bit.ly/1FR7zNW