First published in The Communicator, Spring 2006.

Usability can be quite daunting but this article explains that getting started is easier than you might think.

Introduction

Usability is, without doubt, an essential part of what a technical communicator does. Indeed, as was mentioned in previous issues there is a desire among technical communicators to embrace this concept. But although many communicators appreciate its importance, many don’t realise that taking those first steps is not as difficult as they think. Let’s look at the definition of usability given in ISO 9241-11:

The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context.

On this basis, we can see that if we want to regard a document as usable, readers need to be able to understand it with relative ease, they should be able to accurately follow the instructions they are given and they should be happy with the document and the work they carry out using it. Ultimately, usability involves engineering or producing a document in such a way that it complements human cognitive abilities, compensates for their shortcomings and doesn’t leave them overly traumatised afterwards.

The Problem with Usability

Unfortunately, as anyone who has read any of the literature on usability and human factors will confirm, getting to grips with usability can seem pretty daunting to say the least, especially when we have to take on board the contributions made by cognitive psychologists, learning theorists, software developers, interface designers, writers etc.

Part of the problem with usability is that it is invariably bound up with development and evaluation processes. Then there are the costs and time involved in conducting usability studies and evaluations. What’s more, it is often difficult to apply it to documentation when so much of the existing literature refers to software interfaces. In fact, it sometimes seems that usability is more trouble than it’s worth for the average technical communicator.

It’s Not All Task Analysis

But usability doesn’t need to be all task analyses, prototypes, statistics and empirical testing. Of course, to fully master usability you need to understand the role of cognitive psychology and human factors in usability and conduct task analyses during the design phase of a project to see how best to apply this knowledge. You will also need to know how to conduct usability evaluations which will provide statistically reliable data. But this isn’t essential to start off with.
When you first start exploring usability, it helps to stick with what you know best until you get up to speed with the more detailed stuff. One of the simplest ways for technical communicators to improve the usability of a document is to use carefully selected linguistic strategies; writing techniques that we use every day. In other words, the way we write a document can improve its usability in ways that go far beyond mere readability which is only a measure of how easy the text is to read and not of how easy the information is to use.

Focus on the Documentation

When we produce technical documents, particularly instructional texts, we are essentially creating a device which will help users learn how to use a product. Now we may need to perform some form of task analysis (TA) on the software to determine what content to include in our document, but we don’t need to conduct a TA to determine how to “build” our device. We don’t need to conduct a detailed TA of the process of reading in order to write a usable text. And this is where many people find usability problematic when it comes to documentation.
Unlike software products, reading is a reasonably standardised process governed by human cognitive and learning processes; these processes are essentially the same for the majority of people. What’s more, over the decades reading has been studied and documented to such an extent that there is no need to analyse the process ourselves.
In her incredibly useful book, Coe (1996:134-5) explains that reading consists of the following stages:

1. Perceive visual data
2. Recognise words and letters or learn new words
3. Understand the relationship of words to the entire passage
4. Relate the information to a body of knowledge
5. Encode the information
6. Retrieve the information
7. Communicate the information

If we try to relate these stages to what the literature tells us about human cognition (see, for example, Gavin 1998, Coe 1996, Preece et al. 1994 and Dix et al. 1997) we can see that a number of these stages are going to pose problems for readers.

Short-Term Memory

Short-term memory (STM) is one of the most important components of the human cognitive system, and ironically, it is, perhaps, the one which most restricts our ability to use documentation.
To start with, because STM is limited in its capacity to 7±2 pieces of information (Miller 1956), there is a limit to the amount of textual information we can reasonably expect readers to cope with at any given time. To further limit the capabilities of STM, information stored here generally only lasts for 20-30 seconds (Downton 1991:24).
So how do we tackle this? By keeping our sentences short. Accepted wisdom maintains that sentences should not exceed 20 words or so. Similarly, the 7+2 pieces of information stored in STM are lost as new information is added. If we keep the most important information – the payload – towards the end of the sentence we lessen the burden on readers’ memory and help them remember information more easily while they make sense of the text.
Without burying ourselves in time-consuming task analyses and expensive laboratory studies, we have used two simple ideas which we are all familiar with to adapt a document to a reader’s cognitive ability. This is basic usability engineering. There are numerous ways in which we can use fairly simple and self-contained strategies to improve the usability of a document. The following are just a few of them.

Some Other Strategies

Use consistent terminology
Sometimes it’s tempting to throw in a synonym or two to refer to the same thing. The problem with this is that readers will often wonder whether the two synonyms refer to different things or to the same thing. This polysemy merely serves to confuse the reader and places even greater cognitive burdens on them as they problem-solve to see whether the Print icon is the same as the Print button. Eliminating polysemy reduces interference and confusion for readers. By using words with the same meanings consistently, we help readers learn by taking advantage of the human propensity to form habits.
Use logical sentence structures
If we use simple, logical sentence structures we can reduce the amount of problem-solving needed in order to understand what it is we are trying to say. As a result, we reduce the amount of cognitive effort and consequently the amount of fatigue felt by readers. What’s more, we also lessen the risk of the text being misunderstood – after all, problem-solving isn’t always terribly reliable.
Introduce sections and paragraphs
This aids the learning process. As readers progress through a user guide or even when they dip into a user guide to read a chapter, it is important to tell them what they will find in a particular chapter or large section. This helps them to decide whether the particular section is what they are looking for. Overviews can also help readers absorb, understand and learn information more easily because they mentally prime readers for what they are about to learn and make them more able to remember this information. This phenomenon was proven in an interesting study carried out in 1981 by Foss et al.
Use graphics wherever possible
This lets you take advantage of image memory. This type of long-term memory is more durable and reliable than any other type of memory (Coe 1996:77). When we store information, either in the form of an image or accompanied by an image, we can recall it more readily than information that does not have image associations.

Conclusion

You may have noticed that much of the advice in the preceding paragraphs bears a remarkable similarity to what we generally regard as best-practice in technical writing. This is no coincidence and the reason is that technical writing and usability share the same basic goals – to make “products” easier to use. Indeed, most of the principles of good technical writing are rooted in the same psychological theories as usability (see Dumas & Redish 1999:52-53). It follows, therefore, that judicious use of writing strategies can help us improve the ease with which people can use our documents. Of course, writing represents just one facet of usability engineering but it is one which can be implemented by the vast majority of us without the need for additional training or costly investment in staff and resources.

References

Coe, Marlana (1996) Human Factors for Technical Communicators, New York: John Wiley & Sons, Inc.
Dix, Alan, Finlay, Janet E., Abowd, Gregory D. and Beale, Russell (1997) Human-Computer Interaction (2nd ed.), NJ, USA: Prentice Hall
Dumas, Joseph S. and Redish, Janice C. (1993) A Practical Guide to Usability Testing, Exeter, England: Intellect Books
Foss, J. D, Rosson, M. B. and Smith, P. L. (1981) ‘Reducing Manual Labor: An Experimental Analysis of Learning Aids for a Text Editor’. In: Proc. Human Factors in Computer Systems, ACM, Washington. pp. 332-336
Gavin, Helen (1998) The Essence of Cognitive Psychology, Hertfordshire, England: Prentice Hall Europe
ISO 9241-11: 1998 Ergonomic requirements for office work with visual display terminals – Part 11: Guidance on Usability
Miller, George A. (1956) The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. In: Psychological Review, 63, 81-97
Preece, Jenny, Rogers, Yvonne, Sharp, Helen, Benyon, David, Holland, Simon and Carey, Tom (1994) Human-computer Interaction, Wokingham, England: Addison-Wesley