Quick start guide to usability testing

Good usability means that real people can do real tasks in a reasonable amount of time. The academic definition of usability is more formal, including Learability, Efficiency, Memorability, Error Rate, and Satisfaction. But if you just want a basic understanding of usability, what matters is that real people can do real work.

You can perform a usability test on any kind of information product. An information product can include a website, a set of instructions, a computer application, a physical item, a user manual, and wayfinding signs. Pretty much anything that a real person can interact with is a valid candidate for a usability test. 

Technical communicators can examine usability through a number of different methods, such as a formal usability test, paper prototype testing, animated prototype testing, heuristic evaluations, questionnaires, interviews, and focus groups. Each method has pros and cons depending on the product being tested, its state of development, or the environment in which it will be evaluated.

Let's examine the steps for a popular usability test method: the formal usability test.

1. Personas and use scenarios

To start a usability test, you first need to understand the users. Who is using the system? Why are they using the information product? How are they accessing the system? And what are their goals in using the system? These basic questions form the basis of personas and use scenarios.

A persona is a fictional description of who uses the system. These personas don't need to be very long, but they do need to be realistic. Describe the typical people who access the system using everyday words. A successful persona will sound very familiar; the personas will "feel" like the people who actually use the system.

A use scenario is a fictional account of how a persona uses the system. Again, the use scenario doesn't need to be very long, but it should describe the goals of a real person who uses the system. Also describe how a real person would use the system; this is often relevant in later steps. For example: If the system is a web interface, does the person access it using a phone, laptop, or desktop computer?

I like to write at least one use scenario for every persona. How many you write depends on the different use cases for the system. For more complex systems, you might need to write two or three use scenarios for each persona.

2. Scenario tasks

Once you have defined the users (personas) and how and why they access the system (use scenarios) you can define scenario tasks.

Each scenario task should set a brief context then ask the tester to do something specific. For example, if you wanted to test how easily testers can change the font size in a web browser app, you might ask:

"You forgot your glasses today, so you are having difficulty reading the screen. Find a way to make the text bigger on the screen."

This sample scenario task sets a brief context (you can't read the screen because you don't have your glasses) and asks the tester to do something specific (increase the font size). Scenario tasks form the backbone of a usability test, so these should be created carefully. Avoid giving accidental hints to the tester. Note that the sample scenario task doesn't use the keyword "font" because "font size" is likely to be a menu action in the web browser. Instead, the scenario task asks the tester to make the text bigger. But if the menu action in the browser used the term "text" instead, you might reconsider another way to ask the scenario task.

3. Recruit your testers

To perform a usability test, there is no replacement for watching real people perform real tasks. The scenario tasks are the real tasks. Testers are the real people.

Use the personas as a starting point for finding testers. Ideally, your testers should reflect the personas. For example, if you wanted to do a usability test of a website with technical support information (to be used by PC support technicians) then your testers should have some knowledge of PC support. If you instead recruit nontechnical users who are not involved in computer support, these testers will "discover" problems that aren't really problems.

If you're new to usability testing, you might think you need lots of testers. After all, we might think more data (more testers) will mean better data. But there's diminishing returns as you add more testers. Each tester will uncover the same or similar issues as other testers before them. Testing with twenty testers will provide a lot of data, but most of it will be overlapping data.

You can get "good enough" data by testing with only five or six testers. This provides enough data to generate actionable results - enough that you can make changes to the system.

4. Make changes

The key to using five testers in a usability test is to perform several iterations of usability testing followed by changes to the design. Create an initial design, test it, make changes, then test it again. After two or three iterations, you will likely work your way to a design that works well for most people.