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: Few monster books vs. Many s From:Audrey Choden <AChoden -at- AOL -dot- COM> Date:Fri, 3 Mar 1995 11:31:10 -0500
Robert Busch wrote:
>I'm interested in your opinions -- and if you know of any recent
>research -- on the question of the usability of large, all-inclusive
>manuals vs. smaller, modular manuals.
>Our information development team feels that we should re-organize >a
Programmer's Guide. Currently, it's a monster book (two volumes,
>actually); we'd like to see a series of smaller books documenting
>individual modules, instead. The product we're selling is modular --
>out of around 12 possible modules, customers will typically buy >about six.
>The problem is, our product manager disagrees with us. He likes the "big
book theory." His arguments:
>1. It's more usable, because people won't have to worry about losing
individual books.
>2. When people read about modules they don't have, they might >buy them.
>3. Nobody else in the industry takes the modular document >approach.
>Of course, we have our rebuttals. Argument 1: a good point, but the
>occasional search for a misplaced book isn't as inconvenient as the
>daily challenge of sifting through unnecessary information. >Argument
>2: this book is for users, not potential buyers. Argument 3: the
>documentation in this industry (machine vision) is notoriously poor;
>developers complain about it all the time.
>Of course, modular documentation would be cheaper to administer >(time and
$$).
>Because of unfortunate political circumstances in the company, we
>can't make decisions like this without permission from the product
>manager. And he seems determined to stay with the big book >approach.
>I'd like to support our ideas with usability research, if possible;
>can anyone think of anything relevant?
>BTW, I realize we should make this decision based on user >research; because
of even more unfortunate circumstances, that >isn't possible.
>Sigh.
Having been in a similar situation myself (but as an independent consultant),
I know that all the research and data in the world will not change the
project manager's mind. The issue is perception and control. The project
manager sees himself as the decision maker, has his own preferences (big vs.
small) and likes to maintain the status quo (what's done in the industry).
He's probably concerned with security and safety (his own). You can't change
that. What you might be able to do is influence his thinking so he doesn't
see the new design as a risk and he might even see the change as making him
look good (making the product more competitive because of better
documentation). Another approach is to help him see that by not changing the
design, he might be open to criticism from management (not controlling costs,
etc.)
If it sounds like psychology, it is!
Audrey Choden
Training by Design
achoden -at- aol -dot- com
70471 -dot- 3700 -at- compuserve -dot- com
