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: QUERY: Long vs. Short Manuals From:Adam Rochmes <rochmes -at- WP-CONSULTING -dot- COM> Date:Wed, 17 Jul 1996 14:06:56 -0700
Melinda Carr asked about the advisability of paring down a long (290-page)
manual for a software product that's sold primarily to lawyers and
Whether downsizing can make a document more usable is a terrific question
that's worth asking about any document once in a while. Every situation is
unique and involves using what you know about the your particular product's
users, and the situations in which they use your product, to make decisions
about what information they need. Be cautious about following rules and
For example, how do your users prefer to learn to use the product? People
who want to take time away from their work to study a product may find a
detailed printed manual or online tutorial useful. People who want
just-in-time information to perform an unfamiliar task can take advantage
of information built into the product in the form of prompts, status
messages, and obviousness of the interface -- information that you then may
be able to omit from a printed manual.
How much experience do your users already have in relevant tasks such as
using computers or performing the same tasks without a computer? The more
people can leverage what they already know, the less they may require
What are your users' goals and how much do they really want to know? Many
software users are interested in "how to work it" not "how it works". They
also want to know how get out of trouble or avoid it in the first place.
You may be able to eliminate any technical descriptions of the product's
inner workings, or make that information available on request to the small
percentage of users who want to acquire technical expertise.
Ultimately, the best check on a proposed solution is to perform usability
tests on prototype documentation. This kind of testing doesn't have to be
complicated or expensive. For example, you can compare short sections of
the original manual with comparable sections of a downsized manual. Often
only a few subjects are needed when comparing solutions to decide which is
better (as long as the subjects accurately represent the relevant segments
of your audience).
BTW, Seminars in Usable Design offers a two-day seminar in downsizing
documentation. Their phone number is (303) 234-0123.
I hope this helps.
Adam Rochmes (rochmes -at- wp-consulting -dot- com)
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-