Five Point Quality Test

[sanders_j -at- TBOSCH -dot- DNET -dot- GE -dot- COM]

Hi All,

I was reading some of the articles on quality in the last issue of the STC
Journal, and I got to thinking about how I approach a manual in terms of
quality, and I thought about it some more and came up with the following
five point test. These are basically in order of perceptive impact (or the
order of appearence, if you prefer). This is not just a quality test, I guess,
but also a kind of usability test (aren't they pretty much the same thing?).

Each point will be discussed in full.

1. Appearence
2. Introduction/Startup Stuff
3. Clearly Designed & Structured
4. Super Index (The Find Test)
5. Complete and Informative


Appearence: this is a combination of a number of factors, including not only
how nice the book looks, but also how friendly, graphic layout, type size and
style, screen captures or diagrams of product, and related items. I think it's
especially important to have something that works visually because that's the
way I'm used to thinking, and in general people (IMO) perceive complicated
relationships better if they can "see" them.

Introduction/Startup stuff: this should explain the intent of the manual as a
whole, introduce the product (if appropriate), and provide clear information
on getting started (either with the product or the manual itself). I can't
overstress the importance of good startup/installation information in
software manuals (for instance), because the rest of the manual can be worth-
less if the startup information is faulty or misleading.

Clearly Designed & Structured: the manual should be setup in a logical
fashion that I can use to quickly access information on a particular topic
if I want to. I should also be able to figure out, in general, where the
information I want to find might be. Often the manual can reflect the design
of the product. I am instantly repelled by tables of content that reference
every sub-heading and topic; if the TOC is five pages, something is wrong.
Frankly, I think most of that kind of information belongs in the index, not the
TOC. The TOC is the best tool for showing the structure of your manual.

Index (The Find Test): this is a test of how complete the index is and how easy
it will be for the reader to find information in the manual. If I can't find
something right off under the reference that first came to mind, fine. But if
I can't find it by the third or fourth try: forget it. It fails the Find Test.
I know how great the tempatation is to use the command name as the only index
entry is, and it should be resisted. Building an index for a manual is one of
the most important parts of the documenation process, because it is the part
of the manual that gets  used the most, especially once the reader has been
through the tutorial/setup. My theory on building an index: splatter it; put
every possible permutation of a word, phrase, or concept you can think of into
the index.

Complete and Informative: this is a tough one, but also the final test. If,
when the reader actually arrives at the point of information, they find it
complete and fully informative, then the manual has succeeded. Basically, all
the information the reader needs should be there, and if they need to know
more, it should tell them where to go.


Well, there you go. The world according to John Sanders. I hope this isn't
too pompus sounding, and that it provides everyone with some useful ideas.
(Maybe I should write this up for an article.) Please let me know what you
think, and what you think I
missed.

-John Sanders-
-GE/Schenectady-