Usability Test Script
A session script with tasks phrased as goals, and moderator prompts that do not lead.
Definition
A usability test script keeps sessions consistent and keeps the moderator from helping. It includes the words to say when a participant asks for help.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Fill it in
Loading your draft…
Saved in this browser only. Nothing is sent anywhere.
Setup
Set expectations: testing the design, thinking aloud, no wrong answers, recording consent.
Two or three questions to establish context, before showing anything.
Tasks
Phrase each as a goal with a scenario. Never name interface elements.
Scenario, goal, and what success looks like for your notes.
Order tasks so earlier ones do not teach the answer to later ones.
Include at least one task that is likely to fail. Failures are the findings.
Moderation
Redirect without answering. Write these down so you do not improvise a hint.
The reassurances that contaminate the data.
Opinion questions belong at the end, after the tasks.
What to say when a participant asks for help
Have the words ready. Moderators help by reflex, and every rescue removes the finding the session existed to produce.
| They say | You say | Then |
|---|---|---|
| Where would I click? | What would you try if I were not here? | Wait. The guess is the data. |
| Am I doing this right? | There is no right answer. I want to see how you would approach it. | Return to silence. |
| Is this a test of me? | We are testing the product. Anything that is difficult is a problem with our design. | Say it once at the start, and mean it. |
| I would normally ask a colleague. | What would you ask them? | The question they would ask names the missing information. |
| I give up. | That is a useful result. Before we move on, what were you expecting to happen? | Record it as a failed task, not as a participant problem. |
| What does this do? | What do you think it does? | Only explain after the task is over. |
Moderating
Do
- Phrase tasks as goals in the participant's words, never naming the interface elements.
- Count to five before filling a silence. Most participants resume on their own.
- Ask what they expected to happen, immediately after it did not.
- Take timestamps rather than conclusions, so analysis happens after the sessions rather than during them.
Do not
- Do not answer a question until the task is finished.
- Do not react differently to success and failure, in tone or in face.
- Do not ask whether they liked it. Ask what they would do next.
- Do not change the tasks between participants, or the sessions stop being comparable.
Local chart
TPL·007 · Region VIII · Grid G4
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Often used with
These usually appear in the same screen or the same decision.
- Confirmation BiasBIAS·009 · Cognitive bias
- Curse of KnowledgeBIAS·008 · Cognitive bias
- Guerrilla TestingRES·016 · Research method
- Usability TestingRES·001 · Research method
- Research PlanTPL·001 · Template
Short definition
The one-paragraph version, for when that is all you need.
- Moderated TestingTERM·028 · Term
- Think-Aloud ProtocolTERM·027 · Term