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.
This problem isn't new. Nor is it limited to computer users. The old
saying "When all else fails, read the manual," predates me by a quite a
bit. What is surprising is how frequently this type of thing comes up
with those of use who write the things!
On Thu, 22 Sep 1994
Elna -dot- Tymes -at- SYNTEX -dot- COM wrote:
> > I cite these examples to make the point that books are not *inherently*
> > better at orienting the user. It's a design issue. ...RM
> We just went through a humbling exercise with one of the user groups at
> Syntex. For one project, we've managed to create (against incredible odds)
> a user guide, a set of training exercises and a training database, a Help
> system for the PC, one for the Mac, and a series of presentations that explain
> the system to a variety of audiences who all want different information. The
> members of this group were not allowed to get the software installed on their
> desktop until they went through the training class.
> I was finally allowed to ask this user group (six people in all) how they
> preferred to use the materials they had. None had even opened the User Guide;
> therefore none had discovered the QuickRef card stuck inside the front cover,
> even though it was demonstrated in their training class. Only one of the six
> referred to his marked up copy of the Training Exercises after the class. Most
> did not even know of the existence of the online Help system, despite their
> having done an exercise in the Training that was specifically about the Help
> system.
> I don't feel particularly threatened by this. In fact, I predicted that
> something like this would happen. For one, the FDA requires that any software
> used in the process of clinical research has to have acceptable user docs; for
> another, the documentation had to be in big binders, with copy done on a
> Docutech in order to keep costs down. But what surprises me is that, even
> with that much support, the users didn't use what they had. (They also have
> a hot line to the project manager any time they need help.)
> So this has raised a number of questions in my mind, most having to do with
> how people use the tools available to them. They can gripe and moan about
> useless manuals, and techies in the field can point to the latest in online
> technology as a means of getting information, but I wonder if these aren't all
> somewhat irrelevant. What do you do if your (extremely intelligent but
> incredibly busy) user community won't use the tools available, and the program
> itself isn't particularly intuitive? What to you do about the basic problem
> of overload? Documentation - whether paper or online - can only do so much.
> Elna Tymes
> Los Trancos Systems
****************************************
* RoMay Sitze rositze -at- nmsu -dot- edu *
****************************************
* Mirrors should reflect a *
* little before throwing *
* back images. *
* -Jean Cocteau- *
****************************************
