Re: quality of technical documentation

Subject: Re: quality of technical documentation
From: Wes Tracy <wtracy -at- IU -dot- NET>
Date: Fri, 5 Mar 1999 07:34:06 -0500

Poppy,

I recommend putting a lot of weight on calls received on the help desk or
through customer service. How many questions are asked, how much
troubleshooting help is needed, and how many errors are attributed to the
documentation by the users. These are actual numbers. A little research may
produce a fairly reliable benchmark based on the size or complexity of the
program/product, and the responses in the first month or two after it's
release. These users and technicians are the audience and, IMHO, the best
judges. Please try to avoid a "pages per week" or "total pages" scenario.
I've seen too many instances where 50 or 100 pages are blindly copied from
manual to manual. The users complain that the manuals aren't readable because
of the bulk and repitition, but some lesser managers may actually be stymied by
these complaints because their "pages per week" productivity(?) reports
indicate that that writer is actually the best they have. A well laid out
100-page manual is worth much more to me than a 200-page rambling patch job,
but too many efforts to define productivity reward the 200-page effort.

After having given my slide-rule and calculator approach, I should mention that
there's also the other method--put a comment card at the front or back of the
book.

Either way, good luck.

Wes Tracy
Technical Writing Consultant

Poppy Quintal wrote:

> Can anyone answer the question below from one of my colleagues? We have
> been able to come up with information on various quality methods,
> metrics, etc, but so far nothing that "specifically" allows the
> measurement of quality as a comparison between different sets of
> documentation.
>
> Any suggestions would be appreciated.
>
> ------------------------------------
> We are attempting to attain an accepted and proven form of measurement,
> if not an actual formula, as it relates to the "quality" of technical
> documentation. The assumption is that this "yard stick" could be a
> vehicle that will allow us to grade the quality of our technical
> manuals, compared to those of our competition. Quality, in this context,
> could mean accuracy, readability, consistency, etc. In essence, we are
> trying to acquire concrete empirical results from something quite
> abstract. Is there such a "yard stick" out there that we can use?
>
> Thanks,
>
> Chris

From ??? -at- ??? Sun Jan 00 00:00:00 0000=




Previous by Author: Re: 2 spaces after period - reason why not
Next by Author: Re: FrameMaker 5.1 versus 5.5
Previous by Thread: Re: quality of technical documentation
Next by Thread: Re: quality of technical documentation


What this post helpful? Share it with friends and colleagues:


Sponsored Ads