Home / Archives /

As technical writers, we strive to bridge the gap between those who develop a product and those who will use the product. Our purpose is to make products usable by providing accurate and understandable documentation that meets the needs of the user. We are sometimes confronted with questions about the usefulness of what we are writing. We may ask ourselves, "Have I included all the information a user may need to complete a given task? Am I making assumptions about the user's knowledge? Is the information organized in a manner conducive to the user's needs?"

Often, we become too close to what we're writing to answer these and other questions that arise during the documentation process. One way to discover whether we are successfully bridging the gap is to conduct usability tests.

Usability tests offer the writer opportunities to observe user interaction with documentation during actual product use. Resulting feedback offers insight into potential problems with and shortcomings of the documentation. This insight helps us generate ideas for improving our documentation.

Usability testing actually measures human factors as they apply to performed tasks based on the interaction between documentation and a product user. As technical communicators, we are becoming increasingly aware of the importance human factors have on our profession.

Human factors are the tangible link between what we want the user to do with our documentation and what the user can do with it.

Recently, during a return flight from Seattle, where I attended the University of Washington's "Usability Testing of the Documentation and User Interface of Computer Systems" seminar, I began to consider these thoughts and summarize the basic components of a usability test, based upon what I had learned to be the definition of usability testing.

Professor Judy Ramey of the University of Washington's Department of Technical Communication, which hosted the seminar, defined usability testing as follows:

"Usability testing is a structured process of getting information on specific issues from human subjects typical of the intended users of the product being used. It typically takes place in a cultural and political context specific to a given product-development effort."

As I summarized the basic components of usability testing, I tried to decipher the meaning of each aspect of the definition and how each applies to the actually usability test scenario.

First, I considered what structured process meant. Being a writer for a supercomputer software development department, I decided that the best structured process for my usability test would include a situation where I could observe a real software user attempting to complete tasks based upon documentation I write. This opportunity would place me in a position I'm rarely in; one that allows me to actually see the product user use my documentation.

I also considered the meaning behind the phrase "human subjects typical of intended users." The human subject should be someone other than the software developer, simply because the developer is too familiar with the software and is therefore not representative of the intended user. This conclusion brought me no closer to the definition of "human subjects typical of the intended users."

Ramey suggests that a good subject is one with key characteristics of the intended users, and must be as uncontaminated as possible by the development culture. This implies that the best subject is one who comes from outside the company or from outside the development arena, and one who exhibits traits similar to those of our typical software users. It occurred to me that the best human subject for my usability test is a potential, or existing, customer. I know from past experience that customers are readily willing to help improve our products whenever possible.

To insure against contaminated results, I decided it is best to use enough qualified subjects to counter individual habits that may result in corrupt test data. As with any test lot, the more diverse, the better. Conversely, a test lot too large may have implicit problems of its own such as a volume of data so large as to lose its usefulness. Careful selection of test subjects is, obviously, critical to the resulting data.

Finally, I attempted to define, for myself, the meaning of "cultural and political context" and how this applies to usability testing I may conduct. Based upon information derived from the seminar, I know that the results of a usability test can have implications as a persuasive entity on the development of software. I know from experience that the information obtained from the usability test and its persuasiveness must be used within the confines imposed by my corporate and group culture. It is these constraints that I must consider as I develop and conduct usability tests.

As the plane touched down in Minneapolis, I realized that while the seminar as a whole was very informative, probably the most useful piece of information I acquired was Judy Ramey's definition of usability testing. With that definition analyzed and safely tucked away in my mind, I can develop my usability tests to best suit my needs as a writer and use the resulting data to improve my documentation.

The result will be documentation that does what it is designed to do -- help the user. As writers, we can easily measure our success through the success of those using our documentation to perform given tasks. This performance will continue to be the tangible link between the writer and the user.

Kentucky native Mike Ruhs graduated from the University of Minnesota with a degree in Technical Communication in 1990. He now works as a technical writer for Cray Research. He has been a member of STC for three years.