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.
To Jill (and other interested parties) re: documentation metrics:
You asked about metrics and documentation. It looks like you're on the
right track--reviews, reader comment cards, and usability tests.
There are a few people who have investigated the idea of documentation
quality metrics. In my opinion, coming up with quality metrics for
documentation is VERY DIFFICULT for a number of reasons which I will
enumerate later in this message. Essentially, I'm going to talk about
our approach and our philosophy here at Digital Equipment Corporation.
First, your group/company has to define what a "quality
document" is. Most people say something vauge like "a document that's
usable and on time within budget." Well, it's easy to measure if it's
on time, and it's easy to mesure if it's within budget. but measuring
the usability part is really tough, as I'm sure you know thru the
usability testing.
We contend that the ONLY way to ascertain usability is to
involve USERS in USING THE DOCUMENTATION (ideally, using the doc'n with
the system to accomplish tasks.) In the manufacturing world, it might
be possible to measure whether you have a quality muffler by doing
tests that do not involve people. But because it's ultimately people
who will read our documentation and use our systems, we must involve
users in testing. We can NOT apply a "readability formula" or a
"usability" formula.
Each project/document has its own usability goals. We do NOT
have company-wiode usability standards because it would make no sense
to say "each product MUST be able to be installed within 5 minutes
and by a novice" That's because we sell a huge variety of products.
Thus, we try to create usability goals for each product/solution. We
get the goals by conducting user visits/interview/questionnaires to
find out it, say, users MUST be able to install the software within 10
minutes. Also, we do not do our usability tests in test labs. That's
because a product that's "usable" in a lab may be totally unusable in
the REAL working environment, say, a noisy manufacturing floor, or an
airplane seat when the users' trying to type on a laptop. So we do our
tests in real people's office or in whatever environment(s) we think
are going to be the common ones.
So, that's what we do. We have a 2-day class on "Software User
Documentation:Designing for usability" in which we teach Digital
writers (and external ones,too) the approach and we teach various ways
of creating and setting up such "context-based" usability tests.
Very different from our approach is the approach that Ginny
Redish and others are taking with the development of the "U-Metric
Questionnaire" It's described in the proceedings of the 1992 STC
annual conference (just a 1-pager). Also different is the approach
taken by Bell Northern. Their approach is described in an article by
Bill Hosier, Bob Krull, Phil Rubens, and Chris Vellotta, also in the
1992 STC annual conference proceedings.
So now you have some food for thought,
Mary Beth Raven
Digital Equipment Corp.
Nashua, NH
Raven -at- usable -dot- enet -dot- dec -dot- com
