Ginny Redish focused her seminar on these four points :

1. Introducing usability (i.e. what is usability?)
2. Understanding users and their work before design
3. Interviewing users 
4. Finding out if an organization’s prototypes and drafts work for users (i.e. usability evaluation)

Usability means making sure that the people who will use the product can (1) use it immediately to do their work productively, and (2) easily reach their goals within their own physical and social environments.

In other words, Technical Communicators (TCs) put the users in the centre of their documenting job, because products have no reason to exist without users!

Consequently, TCs should always ask : "What do the users want? What do they expect?" Redish then provided some key word definitions:

• usability (I can find what I need and understand what I find)
• reliability (it works the same way every time)
• accuracy (I can trust what it says)
• functionality (it works the way the specs say it will)
• sufficiency (everything I’m looking for is there).

If TCs are to understand their users, they should also ask: "Who decides what is usable?" In fact, it’s the users who decide

• whether to use the product,
• when to use it,
• how to use it, and
• how much to use it.

Redish stressed the importance of user-centred design, asserting that the users’ needs drive design, not the technology.

Implementing user-centred design means doing user, task, and environmental analyses, creating usability specifications, and performing usability tests. Within this process, TCs have to watch and listen to users and avoid assumptions, i.e. stick to reality. Watching the user means observing the user’s goal, the user’s task, the characteristics of the user, and the characteristics of the environment:

• Capturing characteristics of the user means analysing the user’s prior experience, expectations and mental models, style, and ways of working.
• Capturing characteristics of the environment includes observing the physical surroundings (space, lighting, noise, placement of devices, etc.) and the social and cultural milieu (interactions with others, speed, interruptions, clients, etc.).
• Stressing how to capture the starting point (by defining what kind of information the user has at the beginning) and the end point (by identifying how the user decides when the task is done and what happens next), and whether the user accomplish the expected goal.

TCs have to be good observers and treat the user as a partner. They should write down their observations and separate observations and interferences (assumptions).

In addition to observing users, TCs must also interview them, focusing on

• determining what the user does when the product does not work,
• giving open questions and listening, and
• asking neutral questions.

Remember: a good interviewer listens more than he speaks !

For such interviews, it is important to talk to users one at a time and to create a scenario. A scenario is a short story with a real setting and a real situation that identifies people’s goals, and the task and attributes that are relevant to doing the task.

Usability evaluation means finding out if the prototype document works. TCs should conduct controlled try-outs with one user at a time, and observe the user, recording what the user says and does, analysing the data, and figuring out what is causing problems.

When should a usability evaluation be done?

Usability evaluations should be performed throughout the product development, not just at the end. It is not necessary to have a complete manual, help system or Web site to conduct an evaluation. Usability evaluations are possible for prototypes, navigation, outlines of manuals or help systems, and specific screens or modules.

Finally, when evaluating usability, Redish recommends considering the following three steps to finding the problems:

• Group related instances together.
• Consider how global (widespread) the problem is.
• Categorize the problems by their severity.

Ginny Redish, Ph. D.
President, Redish & Associates, Inc.
6820 Winterberry Lane
Bethesda, MD 20817 (USA)
Voice : 1 + 301 - 229 - 3029
Fax : 1 + 301 - 299 - 2971
E-mail : redish@ari.net
Web : www2.ari.net/redish