Think-Aloud Testing: A Session Script, Annotated Example, and Findings Template

Begin with a task, not a request for design opinions

A member wants to move a pottery class booking from Tuesday to Thursday. The prototype has a 'Manage booking' action, a date picker, and a final confirmation step. The team wants to know whether members understand which class will change and whether the change is complete. Asking 'Do you like this screen?' cannot answer those questions. Watching someone attempt the change while describing what they expect can.

Think-aloud testing asks a participant to put relevant thoughts into words while working on a task, or to discuss a recent interaction afterwards. GOV.UK describes both concurrent and retrospective approaches; each gives access to a participant's account of the experience, with limitations. The account belongs alongside observed actions and system outcomes, not in place of them.

This worked example uses a booking prototype and an illustrative session excerpt to show how to prepare a neutral task, respond when a participant pauses or asks for help, and turn notes into a reproducible finding.

The research question is: 'Can a member change the date of one existing class and accurately tell whether the change has been confirmed?' A complete observation includes the selected booking, the attempted change, the confirmation state, and the member's interpretation. A smooth conversation alone is not evidence of successful task completion.

Choose when to ask for thoughts

With concurrent think-aloud, the participant speaks during the task. This can reveal a moment such as 'I think choosing Thursday has saved it' while the interface is still waiting for confirmation. That timing is useful: it links an expectation to the exact screen. Speaking also adds effort and the facilitator's presence may affect behavior, so this is not a naturalistic speed benchmark.

With retrospective discussion, the participant completes the task before talking through it, sometimes with a recording. It avoids asking them to narrate every action during performance, but the later account may omit or reconstruct what happened. A statement such as 'I probably thought it was saved' should retain that uncertainty; it is not a direct recording of the original thought.

For the fictional booking study, use concurrent think-aloud because the immediate question concerns expectations at the date-selection and confirmation steps. Follow it with a short recap after the task. Keep later explanations labelled as retrospective, and do not silently insert them into the moment-by-moment transcript.

Adapt the method to the participant and task. Talking while using assistive technology can add competing demands, and not everyone finds continuous narration comfortable. Discuss an appropriate approach, allow silence, and record any adaptation. A quiet participant has not supplied evidence of either confusion or ease merely by being quiet.

Prepare a realistic start and a neutral introduction

Use a test account with a visible Tuesday pottery booking and an available Thursday alternative. The prototype should show the relevant states consistently. If the confirmation cannot actually be completed, declare that limit in the research plan and define what observable prototype state can be evaluated. Do not let a prototype dead end become a finding about the participant's ability.

Give the participant a goal, not a route: 'You can no longer attend your pottery class on Tuesday. You would like to attend the Thursday class instead. Use this account to make that change, and tell me when you think you are finished.' Do not mention Manage booking, the date picker, or the final button. Those are parts of the design whose meaning is being examined.

Before starting, explain: 'We are testing the booking experience, not you. As you work, please tell me what you are looking for, what you expect, and anything that surprises you. You do not have to explain or defend every choice. You can pause or stop. I may stay quiet so you can decide what to do.' Obtain permission for the recording and explain how it will be used before recording begins.

A short unrelated practice task can make the technique less strange. For example, ask the person to choose a snack from a small menu while describing what they are considering. The demonstration should show ordinary thoughts, not model the booking route or reward a particular style of answer. Keep the real task separate from the warm-up.

Prepare the observer's note format in advance and test the recording setup with non-sensitive data. If using a prototype, reset it to the same initial state for each session. An accidentally retained Thursday selection would change the task before the participant has made any decision.

Respond to silence and help requests without teaching the interface

The facilitator's job is to make room for the participant's account. If the person is reading, a pause may be appropriate. Repeatedly asking questions can turn the session into an interview about hypothetical behavior while the actual task stalls. Use a brief neutral reminder when needed, then return to observing.

If the participant asks 'Should I click this?', avoid nodding or saying 'Yes, that's right.' A neutral response might be 'What would you do if you were using this on your own?' If they remain stuck and further observation is no longer useful, provide a planned level of help and record exactly when it occurred. The remainder can still reveal problems, but it is no longer an unassisted attempt.

A question can be open-ended and still lead. 'Why did you ignore the confirmation button?' assumes the button was seen and should have been used. 'What are you looking for now?' does not impose that explanation. Save detailed probing for a natural stopping point or the post-task discussion so the prompt does not create the behavior you later report.

Do not demand that someone justify every choice. An explanation offered under pressure may be a reasonable story constructed for the researcher rather than the reason that drove the action. Record the words and circumstances without presenting narration as a complete window into cognition.

Keep action, speech, and interpretation in separate notes

In the invented session, the participant selects Thursday and says the booking is changed, but the screen still requires a confirmation. The observation is not simply 'The button is unclear.' The useful evidence is the sequence: the selected date changes visually, no final confirmation has occurred, and the participant believes the change is complete.

The excerpt below deliberately includes the moderator's words. Without them, a reader could mistake an answer elicited after a prompt for a spontaneous statement. The times are illustrative sequence markers, not measured timing data. Use actual timestamps or recording references in a real session, and distinguish verbatim quotations from paraphrased notes.

At the end of the excerpt, the participant selects Confirm change after the facilitator directs attention to the unfinished state. That completion is assisted. Do not count the eventual confirmation as unassisted success or remove the assistance because it seems minor. The assisted continuation may still show whether the confirmation and updated booking are understandable.

An alternative explanation remains possible: the person may have seen the button but assumed it was optional. The narration and screen sequence suggest an expectation mismatch, but they do not isolate its visual cause. Keep that interpretation provisional until the evidence supports a more specific mechanism.

Turn the excerpt into an actionable finding

A useful finding states what happened, under which conditions, and why it matters to the task. For this example: 'In prototype V1, changing the selected date was mistaken for completing the booking change. The participant stopped before Confirm change and said they would close the page. The booking had not yet been updated.' The supporting evidence is the excerpt and corresponding screen states, not a generic claim that users dislike extra steps.

Separate that finding from the proposed repair. One possible direction is to make the pending selection explicit: 'Thursday selected — review and confirm to change your booking.' Another is to place the review and confirmation in a clearer sequence. Those are design hypotheses. The test does not establish which one will work, and it does not justify adding a misleading 'Saved' message before the change is actually saved.

Across multiple sessions, compare the same task conditions and preserve differences. If one person stops early and another completes the change but misunderstands which class moved, those are related but distinct problems. Counting both under 'booking confusion' can hide different remedies. If you report counts, use people or attempts consistently and state the denominator; three comments by one person are not three independent participants.

Judge severity in context: how likely is the misunderstanding, what task does it prevent, and how hard is recovery? Distinguish an observed incomplete booking change from possible later consequences, and collect the evidence needed for that judgment.

Retest the change and report the limits plainly

After the design is revised, repeat the relevant task with an appropriate participant and a reset account. Observe both the action and the person's interpretation. A participant may click the final button while still believing that the earlier date selection had already saved the change. The meaning check helps distinguish successful interaction from an accurate understanding of the state.

Test the successful confirmation and relevant failure states. If the Thursday place becomes unavailable, the interface should explain the actual outcome; it should not imply that the booking moved merely because Thursday remains selected. The specific error branch belongs in the plan if it is part of the confirmed research question. Do not silently mix success and failure fixtures when comparing results.

Close the report with the task, participants and recruitment boundaries, material version, method, assistance, observed outcomes, and remaining uncertainty. Separate findings from preferences and proposed fixes. A preference such as 'I would make the button blue' may prompt a design idea, but it is not itself evidence that colour caused the missed confirmation.

The reusable record below can be copied into a session notebook. Fill the observation first, then write the interpretation and next action. This order makes it harder to let an appealing explanation replace what the participant actually did. A good think-aloud study leaves the team with a specific problem it can reproduce and a question it can test again.

References

• GOV.UK: Think-aloud study methods
• NN/g: Thinking aloud in usability testing

Continue reading

• Heuristic Evaluation: A Worked Example and Issue Report Template