THE RESULTS

What are the elements usability testers measure? According to Mills and Dye, “Three main classes of information are collected in usability tests:

logs, objective measures, and subjective measures.” Logs record testers’

observations, users’ keystrokes, and “verbal protocols (thinking aloud).”

Objective measures include things like the number of errors made and the amount of time it takes to perform a task. Subjective measures include the users’ feelings and opinions about the product, which testers will collect through interviews and questionnaires.⁸

Conclusions drawn from these data depend on the kind of documen-tation and the nature of the tasks the user performs. You wouldn’t need to be a trained social scientist, though, to understand the grosser prob-lems expressed by test subjects in the sessions I observed.

FOLLOW-UP

No amount of research will help you if you don’t use what you’ve dis-covered to improve your documentation. You may think this goes with-out saying, but I’ve found it’s not as obvious as it seems. At one company where users were disgruntled about documentation, I was sent to find out why. “Design a survey,” my boss suggested. I designed one, with ques-tions similar to those you’ll find earlier in this chapter in the section titled

“Site Visit.” I submitted it to user groups both in the United States and in Europe. Customers were obviously pleased to have their opinions solicited, because a large percentage returned my questionnaire. The results were easy to analyze, because the majority of users requested the same improvements: more illustrations, a better index, and more techni-cal information on a more sophisticated level. They didn’t care about the attractiveness of the manual’s cover. They just wanted the facts.

I presented the results at a department meeting and made concrete suggestions about how to give the users what they’d requested. Everyone was in agreement. But it never happened. The survey, it turned out, had been a gesture of diplomacy. Management did not intend to implement changes. Seven years later, that company’s customers still complained about documentation, and the company had lost revenue. Then, when the company was acquired by a larger corporation, the publications depart-ment was disbanded, followed shortly by the company itself. The moral of the story? Pay attention to your audience!

Enlist the support you’ll need from management and fellow workers before you begin to investigate your audience. Prepare a concrete plan to give your readers what they need.

What are some of the elements you’ll modify based on your findings about your audience? Some obvious ones already mentioned include level of technical complexity, amount of detail, number of illustrations, and formality of language.

When Keeler found a significant minority of her test subjects were

“nonreaders”—that is, they read fewer than five newspapers, books, or magazines per month—she recommended using “lots of headings, mar-ginal notes, illustrations, and bulleted lists.”⁹ These recommended ele-ments are standard tools tech writers use to break up the printed page.

More about them in the chapter “Planning for Visual Impact.”

Other document features based on audience might be unique to your user and might require you to find a more creative solution. The example of the airplane mechanic in the mud is a good one, and the plastic-laminated task card is, I think, a good solution. Others might include pro-viding the following:

• labeled, colored tabs in a binder that is used often as a reference

• a quick-reference card that folds to stand up by itself, for users who need both hands to perform a task

• extra blank pages for taking notes, should your readers have a spe-cific need to do so in a document

• an online document, a portable computer, and a modem, for travel-ing workers who need instant access to most-current data

These are just a few examples of ways to creatively apply what you know about your audience to your documentation choices

SUMMING IT UP

This chapter described ways to find out who your audience is and what they need from your manual to do their jobs. It recommended some ways you can use this information to improve document usability. The next chapter begins a new section, which describes the birth of a document

and its passage through writing, editing, review, and production. It pro-vides guidance for planning both paper and online documentation.

1Jonathan Kozol, Illiterate America (New York: Anchor Press/Doubleday, 1985), p. 20.

2Thomas M. Duffy et al., “An Analysis of the Process of Developing Military Technical Manuals,” Technical Communication, Journal of the Society for Technical Communication, Second Quarter, 1987, p. 70.

3Kozol, p. 18.

4Stephanie Rosenbaum, “Selecting Appropriate Subjects for Documentation Usability Testing,” Work with Computers: Organizational, Management, Stress and Health Aspects, Proceedings of the Third International Conference on Human-Computer Interaction, Boston, Mass. September 18–22, 1989 (Amsterdam, Netherlands: Elsevier Science Publishers B. V., 1989), p. 621.

5Heather Keeler, “A Writer’s Readers: Who Are They and What Do They Want?” Technical Communication, Journal of the Society for Technical Communication, First Quarter, 1989, p. 9.

6Keeler, pp. 10–11.

7Carol Bergfeld Mills and Kenneth L. Dye, “Usability Testing: User Reviews,” Technical Communication, Journal of the Society for Technical Communication, Fourth Quarter, 1985, p. 40.

8Mills and Dye, pp. 42–43.

9Keeler, p. 11.

PART 3