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: measuring productivity and QUALITY From:"Peter Ring, PRC" <prc -at- ISA -dot- DKNET -dot- DK> Date:Sat, 21 Feb 1998 18:24:40 +1
A very interesting discussion!
I have worked a lot on measuring quality of technical documentation.
The results so far are my book "The PQM system - How to write better
instruction manuals, and control their quality yourself!", the PC
programme PQM 2.3 which can assist you in measuring the quality of a
manual, my internal and external courses, - and a lot of manuals with
a good user response.
When I in the following refer to "manual" it includes all kind of
instructional material on paper or on-line.
Basically there are two dimensions:
The first dimension is the phase of the manual "production":
1. Planning and writing phase. Is the manual goint to fulfil the
goals set, incl. fulfilling the needs of its target group(s)?
Measure: PQM points (see my book). After the measurement, any
fundamental problems and little details will normally be solved.
2. Usability test phase. Does the users like it? Does it work? How
many errors? Measure: Problems encountered during the test
(number, course, and severity). After the measurement, the
problems found will normally be solved.
3. The users' use of the manual. Does it temp them to use it? Does
it fulfil their needs? Measure: Number of support/service
calls. Problems identified should be solved, but most often
it's only the small problems which is solved, fundamental
problems like "written on a too high level" are rarely solved.
The second dimension has to do with the functionality of the manual:
The functionality can be divided in four groups:
- Paedagogical quality: Is the manual written for the "typical weak
user" in its target group? Does it follow the more or less well
known rules for how to write a good manual? Does it contain what
it should contain?
- Technical quality: Is the information in the manual correct? Is
any important info missing?
- Linguistic quality: Number per e.g. 100 pages of spelling errors,
grammatical errors, terminology errors? Ambiguity - nice and clear
language or complicated language? (Mechanically measured
"readability" is a part of the paedagogical quality measurement).
- Graphical quality: Follows graphical line? Decent lay-out? Paper
and printing quality (if printed)?
Each of these four points contains a number of weighted parameters.
The funny thing is, that to my experience it doesn't take much more
time to write a good manual than a bad one. Often even less if you
are used to write in a user friendly way and know what's important
First of all the quality should be OK. But if you are a documentation
manager, you know which people in your department are solving the
problems of producing a decent manual within a reasonable time, and
who are not. But it will be a sort of "felt average" over many
projects. For a single specific project it is very difficult: too
many factors like the quality of the information you base it on,
product changes during the documentation, availability of the technical
experts, just to mention a few.
I could go on for days but I'll stop here.
Greetings from Denmark
PRC (Peter Ring Consultants)
- specialists in user friendly manuals and audits on manuals.
prc -at- isa -dot- dknet -dot- dk
- the "User Friendly Manuals" website with links, bibliography, list
of prof. associations, and tips for technical writers: http://isa.dknet.dk/~prc/
- text cleaning software, e.g. for reading difficult e-mails: http://isa.dknet.dk/~prc/software/index.html