6.3 Think Aloud
discovering what people are thinking as they use your sketched interface
Chapter 6.1 showed how you can uncover a person’s initial mental model formed when he or she sees your sketched system for the first time. Yet that technique does not reveal how that person’s view of your system unfolds as he or she actually tries to use it.
Passive observation is one simple but not particularly effective method. The idea is that you introduce the sketched system to a person, and then you observe how that person uses it. Observation lets you see the person’s physical acts. From these, you can perhaps infer what is going on. Hesitations suggest difficulties. Successful quick actions suggest no problems. Incorrect actions suggest mis-understanding and errors. However, your inferences will be superficial, as you will never really know what is going on in a person’s head.
This is where the think aloud method helps. As briefly introduced in Chapter 6.2, the approach is to have people think aloud, where they say what they are thinking as they use your sketch to do a task. This method is easy to learn, cheap, simple and fast to do. Yet it can reveal a significant amount of information, especially usability problems. As Gomoll and Nicol [1990] explain,
“by listening to participants think and plan, you can examine their expectations for your product, as well as their intentions and their problem solving strategies.”
Catching and repairing usability and conceptual problems during the early design phase can lead to significant savings in the development process. These and other reasons explain why think aloud is the most frequently used evaluation method employed by professional user experience designers and usability engineers.
There are many books that describe the think-aloud method and its variations. Some go into great detail, as in Dumais and Redish’s Practical Guide to Usability Testing. Books like these should be required reading if you are taking usability testing seriously, as they go into excellent detail about how to set up studies, how to define tasks, how to prepare for the test, ethics in running a test, and so on.
However, a few simple steps can get you going right away. Perhaps the shortest and best summary of think aloud was produced by Gomoll and Nicol in their 1999 paper: User Observation: Guidelines for Apple Developers. This chapter reproduces liberally from these guidelines, albeit (with apologies to them) in a somewhat pictorial, modified and summarized form.
a. Set an objective. Take time to figure out what you’re testing and what you’re not. In other words, determine an objective that focuses on a specific aspect of the product. By limiting the scope of the test, you’re more likely to get information that helps you solve a specific problem.
b. Design the tasks. You should give your participant one or more specific tasks to do. These tasks should be real tasks that you expect most users will do when they use your product. After you determine which tasks to use, write them out as short, simple instructions.
c. Prepare your sketch so that people can interact with it. If you want to explore how people do particular tasks, make sure that the expected interaction sequences are available (e.g., as in a scripted slide show, described in Chapter 4.1). When a person does an action, you can then manually switch the sketch to the next scene. Alternately, use a branching storyboard (Chapter 4.3) to have the system give the illusion that it is actually responding to them. Or you can reveal system responses via Wizard of Oz (Chapter 6.2). Your sketch doesn’t need to cover everything; your on-going instructions can limit the scope of what your test user should be trying to do.
d. Prepare equipment. If you are audio or video-recording the session, make sure it’s set up ahead of time and working well.
To get you ‘in the groove’, try a think-aloud test using an existing software system.
A web page to (say) an airline site would be an excellent example. Create a few tasks, starting from a simple one to increasingly complex ones. For example:
a. Find a flight that goes from here to Los Angeles, leaving tomorrow.
b. Find the cheapest flight that goes between these two cities, where you would prefer to leave late in the day but come back first thing in the morning a week later.
c. Find an itinerary that goes from here to London, stops in London for two days, then continues on to New Delhi, and then returns here a week after that.
Using the fax machine sketch from Chapter 6.1, do a usability test of it. For example:
a. Here is a 1-page fax. Send it to 222-3333.
b. You think the fax machine can save phone numbers so you can recall them later. Save the number 222-3333 to the fax machine. Once you’ve done that, recall it and send that fax to it again.
Note that you may have trouble with the above, as you don’t know how this particular fax machine works and thus can’t really simulate what will happen using Wizard of Oz. But try it anyway – you will still learn a lot about where people will stumble.