A good usability testing script gives participants a goal and gives the moderator a consistent way to observe what happens. When a task tells someone to click “Advanced delivery settings,” you learn whether they can follow the instruction. To find out whether they would discover that control on their own, give them a reason to change the delivery time and let them choose where to start.
Start with a research question and a stopping point
Write a question the team can answer by watching behavior. For a digest settings page, ask whether participants can set up a weekly digest, change the time it arrives, and stop delivery without losing their account. Then identify evidence for each task. If someone toggles a setting and assumes it saved automatically, record what they did and what they believed. Those are two separate observations.
Decide when each task ends. You might stop when the correct settings are saved and the participant explains the resulting schedule, when the timebox runs out, or when they say they would give up. Keep these criteria in the moderator’s copy. Give participants a believable situation and a goal. The GOV.UK Service Manual’s moderated testing guide describes preparing neutral tasks and a consistent discussion guide.
A 30-minute usability testing script you can adapt
Minutes 0–5. Welcome, consent and setup
“Thanks for joining. We’re studying how people manage email updates. I’ll ask you to try a few things using a test account. You can pause, skip a task or stop at any time. As you go, tell me what you’re looking for or what you expect to happen.” Explain what will be collected, who can access it, and how it will be handled under your study’s consent process. Ask separately for permission to record before starting the recording. If recording is optional and declined, use the agreed notes-only process.
Check that the participant can see and use the interface with their preferred equipment. For remote sessions, confirm which window will be shared. Provide dummy data where the prototype should not receive personal information. Ask one warm-up question, such as “Tell me about the last time you changed which emails a service sends you.”
Minutes 5–12. Set a weekly digest
“You get too many separate emails from this service. You still want to hear what happened, but you only want one summary each week. Show me how you’d set that up.” Record the first action, whether the participant changes frequency and saves, and whether they understand what messages the setting affects. A useful follow-up is “What emails would you expect to receive now?”
Minutes 12–19. Adjust the delivery time
“You now work from a different time zone. You want the weekly summary to arrive at 9 a.m. where you work. Show me what you would change.” Set the prototype to a known time zone first. Observe how the participant locates the control and whether the final summary reflects the right local time. Keep the expected time zone and save state in your private notes.
Minutes 19–25. Stop delivery
“You’re leaving this project and want the summary emails to stop. You still need access to the account. Show me what you’d do.” Observe whether they disable the digest, find a different email control, or start an account-level action. Ask what they expect to happen to their access and previously received messages. Reset the prototype between participants so everyone starts from the same state.
Minutes 25–30. Debrief
Ask about moments you actually observed. “You paused after changing the time. What were you looking for at that point?” Follow with “What would you have done next if you were doing this on your own?” Thank the participant and explain what happens next with the research.
Rewrite instructions that give away the answer
| Leading wording | Neutral wording |
|---|---|
| Open Advanced delivery settings and select your time zone. | Make the digest arrive at 9 a.m. in your current time zone. |
| Did the confirmation message reassure you? | What do you think happened after you saved? |
| Use the unsubscribe switch to stop emails. | Stop these summaries while keeping access to your account. |
When a participant asks where to go, give them time to try another route. If they need a prompt, begin with “What would you try next?” If you provide a hint to keep the session moving, write down the hint and record the outcome as assisted. Agree on this rule with your note-taker before the first session.
Log evidence and keep the prototype version stable
Use one row per participant and task, with columns for first action, observed path, outcome, help given, and a short quote or timestamp. Separate an observation such as “opened billing twice” from an interpretation such as “expected email settings to live in billing.” The distinction helps the team decide whether a label, navigation route or expectation needs closer examination.
Prompt-to-prototype tools make it possible to revise flows between sessions. Save a version for each round so changes to text, defaults or routing do not get mixed into the same findings. If you fix a broken route mid-round, record which participants saw each version. Use automated summaries to help locate evidence, then check important claims against session notes or the agreed recordings before sharing them. Figma’s introduction to prompt-based prototyping.
Run a pilot and decide what to report
Before recruiting, ask a colleague to follow the script literally. Check for hidden prerequisites, accidental hints and setup steps that consume the time reserved for observation. For example, a browser might open the settings page already scrolled to the timezone control. Reset the scroll position and account state before each session if discovery is part of the question.
After the pilot, standardize a short handoff between tasks. If the first task leaves the digest disabled, the second participant may be unable to set its arrival time. Restore the state needed for the next task and note when you do it. If you need to study how errors carry over between tasks, keep the state and report that choice explicitly.
Summarize findings in terms of actions and consequences. A report might say that several participants found the weekly option but left before saving, then show the corresponding observations and distinguish assisted outcomes. Use the sessions to identify what to change and what to test next. A small moderated round can reveal a recurring problem without establishing how often it occurs across the full user population.
Also read
- Progressive Disclosure UX for deciding which settings to show and testing whether people find the rest.
- Accessible Form Design for turning keyboard and error-recovery checks into concrete tasks.
