Think-aloud testing

Definition: In a thinking aloud test, you ask test participants to use the system while continuously thinking out loud — that is, simply verbalizing their thoughts as they move through the user interface.

The method has a host of advantages. Most important, it lets you discover what users really think about your design. In particular, you hear their misconceptions, which usually turn into actionable redesign recommendations: when users misinterpret design elements, you need to change them. Even better, you usually learn why users guess wrong about some parts of the UI and why they find others easy to use. 

The thinking aloud method also offers the benefits of being:

-       Cheap- No special equipment is needed; you simply sit next to a user and take notes as he or she talks. It takes about a day to collect data from a handful of users, which is all that’s needed for the most important insights. 

-       Robust- Most people are poor facilitators and don’t run the study exactly according to the proper methodology. But, unless you blatantly bias users by putting words in their mouths, you’ll still get reasonably good findings. 

-       Flexible- You can use this method at any stage in the development lifecycle, from early paper prototypes to fully implemented running systems. 

-       Convincing- Even the most arrogant designers usually listen when they get direct exposure to how customers think about their work. 

Downsides to think-aloud testing:

-       Unnatural situation- Most people don’t sit and talk to themselves all day, this makes it hard for the test participants to keep up with the required monologue. Usually though most users typically are quite willing to try their best. 

-       Filtered statements (vs. brain dump)- Users are supposed to say things as soon as they come to their mind rather than reflect on their experience and provide an edited commentary after the fact. However, most people will think about their answers first. 

-       Biasing user behaviour- Prompts and clarifying questions are usually necessary, but from an untrained facilitator, such as interruptions can very easily change user behaviour. In such cases, the resulting behaviour doesn’t represent real use, so you can’t base design decisions on the outcome.