Write a usability test script

Outcome

A script of one to two pages that every session follows word for word: a research question at the top, an introduction, two or three background questions, three to five tasks written as goals, a follow-up after each task and a short debrief. It has been piloted once and fixed.

When to use it

• You are about to run a moderated or unmoderated usability test and more than one session will happen.
• More than one person will moderate, and you need the sessions to be comparable.
• You want to test a specific flow or decision, not to "get feedback" on a design.

When not to use it

• You want to understand people's work, motives or workarounds before there is a design. That is an interview; run a user interview.
• You want to know how many people prefer A over B. A usability test with five people cannot tell you; use a preference test or a survey.
• There is nothing to put in front of participants yet. Write the research question now and the script when a prototype exists.

Before you start

• The research question. One sentence: what will the team decide after watching these sessions?
• The prototype or build. The flows the tasks need must work, including the error states you want to see.
• The participant profile. Who you are recruiting and what they already know, so tasks can match their situation.
• A pilot participant. One person who fits the profile, or close to it, available a day before the real sessions.

Steps

Step 1: Write the research question at the top

Write the decision the test feeds, as a question, such as can a new admin invite their team without help? Every task in the script must help answer it. If a task does not, it goes.

You should now have: one research question at the top of the script that every task can be checked against.

Step 2: Write the introduction the moderator reads aloud

Write it as spoken words: who you are, how long the session takes, that you are testing the product and not them, that confusion is useful, that you may not answer questions during tasks, and a request to think aloud. Add the recording consent line. Keep it under two minutes when read.

You should now have: an introduction of under two minutes, written as speech, including consent and the request to think aloud.

Step 3: Add two or three background questions

Ask about the participant's recent experience with the task area, such as when did you last set up a new tool for your team, and how did it go? Ask about recent behaviour, not opinions. These questions warm the participant up and give you context for what you will see.

You should now have: two or three background questions about recent behaviour.

Step 4: Write each task as a goal with a reason

For each part of the flow, write a scenario that gives a realistic motivation and an end state, and no instructions. Remove every word that appears in the interface's labels or navigation. Write a success criterion for each task beside it, for the moderator only.

You should now have: three to five tasks written as goals, each free of interface vocabulary, with a success criterion for the moderator.

Step 5: Order the tasks and add a follow-up after each

Put the task most important to the research question first or second, while the participant is fresh. Order the rest the way a real person would meet them. After each task, add one neutral follow-up, such as how did that compare to what you expected?

You should now have: tasks in session order, each followed by one neutral follow-up question.

Step 6: Write the debrief

End with two or three questions about the session as a whole: what stood out, what they would change, anything else to add. Close with thanks and the incentive. The debrief collects opinions, so it comes after all the behaviour you came to watch.

You should now have: a debrief of two or three questions and a closing line.

Step 7: Pilot the script once and fix it

Run the full script with the pilot participant, timed. Note every task that was misread, impossible in the build, or solved by a word in the task. Rewrite those and cut tasks if the session ran long.

You should now have: a piloted script, fixed and timed, ready for the first real session.

Worked example

A team building an expense tool is about to test its new team set-up flow with five office managers.

1. Research question: can a new admin invite their team and set a spending limit without help?
2. The introduction is 180 words and asks the participant to say what they are looking for as they go.
3. Background: the last time you set up a tool for your office, who did what? and how do you handle expense limits today?
4. Tasks: Your company just signed up. Get the four people in your office using it before Monday. — success: four invites sent. Your new hire keeps buying first-class train tickets. Make sure that cannot happen again. — success: a per-person limit saved. The first draft of the second task said "set a spending limit", the label on the button; the rewrite removes it.
5. The invite task goes first, because it is the one the research question depends on.
6. Debrief: what was the hardest moment? and what would you tell a colleague about setting it up?
7. In the pilot, the participant asks whether "the people in your office" includes themselves. The task gains besides you. The session runs 38 minutes, so one lower-priority task is cut to fit 30.

Checklist

• The research question is written at the top and every task serves it.
• The introduction is written as speech, takes under two minutes and includes consent.
• Background questions ask about recent behaviour, not opinions.
• Every task is a goal with a reason, with no interface labels in it.
• Every task has a success criterion only the moderator sees.
• The most important task comes first or second.
• The debrief comes after all the tasks.
• The script was piloted once, timed and fixed.

Common mistakes

• Instructions disguised as tasks. "Go to Settings and invite your team" tests whether people can follow directions, not whether they can find the feature.
• Using the interface's words. If the task says "workspace" and the menu says Workspace, you will never learn that nobody knows what the word means.
• Asking for opinions mid-task. "Do you like this screen?" stops the behaviour you came to observe. Save opinions for the debrief.
• Too many tasks. A rushed participant stops thinking aloud. Three to five tasks fit a 30-minute session.
• Skipping the pilot. The first real participant becomes the pilot, and their session is spent on a broken task.

Related

• First-Click Test: run one task from the script against a single screen and see where the panel clicks first.
• Five-Second Test: check what people take away from a screen before you script tasks on it.
• Run a heuristic evaluation: clear the obvious problems before you spend sessions on them.
• Run a user interview: when the question is about people's work, not the design.
• Usability testing basics course: the method in lessons with knowledge checks.
• Usability Testing — A Step-by-Step Guide: the whole test, from method choice to the ranked list of fixes.