Usability testing script template
Template · 8 min read · By Utkarsh Dhairya Panwar · Updated
A usability testing script has five parts: an introduction with consent, a short warm-up, three to five task cards read word for word, a question after each task, and a wrap-up. Below are the full moderator script, a task card template, neutral prompts and a note grid.
Before the first session
- Write down the two or three decisions this test should inform. A finding that can't change a decision isn't worth a task.
- Build the prototype paths for failures too: a timeout, a decline, an empty account. Happy-path prototypes only test the happy path.
- Recruit five to eight people who match the real users, and one spare for no-shows.
- Assign roles: one moderator who only talks, one note-taker who only writes. Observers stay muted with cameras off.
- Run a pilot with a colleague. Every script has one badly worded task, and you want to find it before participant one.
The moderator script, word for word
Read it aloud exactly as written. When every participant hears the same words, differences in behaviour come from the design rather than your phrasing.
- Introduction (2 minutes): "Thanks for joining. I'm [name], and I'm helping design [product]. Today I'll ask you to try a few things in an early version of the app. I'm testing the app, not you, so there are no wrong answers. If something is confusing, that's exactly what I need to know. I didn't design every part of this, so you won't hurt my feelings."
- Consent (1 minute): "With your permission I'd like to record the screen and audio, only so the team can review it later. It won't be shared outside the team. Is that okay? You can stop at any point." Start recording only after a clear yes.
- Warm-up (3 minutes): "Before we start, tell me about the last time you [did the thing the product helps with]. What did you use? What was annoying about it?" Listen; don't take notes on the product yet.
- Think-aloud setup (1 minute): "As you go, please say what you're thinking: what you're looking for, what you expect to happen, what surprises you. If you go quiet I might remind you."
- Tasks (15 to 25 minutes): Read each task card's scenario exactly and hand over control. Say nothing until the participant finishes, gives up or hits the time cap, then ask the post-task question.
- Wrap-up (3 minutes): "Of everything you did today, what was the most frustrating moment? If you could change one thing, what would it be? Is there anything you expected to see that wasn't there?" Thank them, confirm the incentive, stop recording.
The task card template
Write one card per task. Most templates stop at the scenario, but the success and failure lines are what make five sessions comparable.
| Field | What to write |
|---|---|
| Task name | Short, for your notes only. Never read it aloud, it gives the answer away. |
| Scenario (read aloud) | A goal and a reason, in the user's words, with no UI labels. Not 'tap Retry' but 'you want to finish buying this'. |
| Starting point | The exact screen and state the prototype opens on. |
| Success looks like | The observable end state. 'Payment confirmed screen reached, with one charge.' |
| Partial success | Finished with a hint, or by a path you didn't intend. |
| Failure looks like | Gave up, hit the time cap, or believes they finished when they didn't. |
| Time cap | Usually two to three times what it takes the team. |
| Post-task question | 'On a scale of 1 to 7, how easy or hard was that?' then 'What made it that way?' |
| What you're watching for | The specific doubt behind this task. Never read it aloud; it's for the note-taker. |
Example task: a failed payment and a retry
At FamPay (YC S19) I worked on what the iOS app shows when a payment times out, gets declined by the bank or needs a retry, and I tested those states with users. This card is modelled on those sessions.
| Field | Example |
|---|---|
| Task name | PAY-02 Retry after timeout |
| Scenario (read aloud) | "You want to buy a ₹200 Amazon voucher for a friend's birthday using money in your account. Go ahead and buy it." |
| Starting point | Voucher detail screen, balance available. Prototype is set to time out on the first payment attempt. |
| Success looks like | Participant retries, reaches the confirmation, and can say they were charged once. |
| Partial success | Completes the retry but says they're unsure whether money left their account. |
| Failure looks like | Abandons, taps back out of the flow, or pays again from scratch believing the first attempt failed. |
| Post-task questions | Ease 1 to 7. Then: "What do you think happened to your money the first time?" |
| Watching for | Do they find retry? Do they understand no money moved? Do they double-tap? |
Keep the question about money even if you cut the others. In a payment flow, finishing the task and feeling sure about the money are different things, and task success only measures the first. At FamPay the gaps worth fixing were in the feedback about what had happened, rather than in the payment form. The payment failure guide shows what I changed.
What to say when someone gets stuck
| Instead of | Say |
|---|---|
| "Did you see the Retry button?" | "What are you looking for right now?" |
| "Was that confusing?" | "Tell me what just happened." |
| "Great, perfect." | "Okay." Praise teaches people what you want to hear. |
| "Why didn't you tap that?" | "What did you expect that to do?" |
| Answering their question | "What would you do if I weren't here?" |
| Silence for three minutes | After a long stall: "What would you try next?" If still stuck, note it as a failure and move on. |
The note grid
Use one grid per task and one column per participant. The note-taker fills it in live; the moderator never writes. After five sessions you can read a pattern across a row in seconds.
| PAY-02 | P1 | P2 | P3 | P4 | P5 |
|---|---|---|---|---|---|
| Outcome (S / Partial / F) | |||||
| Time to finish | |||||
| Path taken | |||||
| Hesitations (where, how long) | |||||
| Errors or wrong taps | |||||
| Ease score (1 to 7) | |||||
| Best quote | |||||
| Belief about money / outcome |
Within 30 minutes of each session, the moderator and note-taker spend five minutes agreeing the top three observations. After the last session, any problem seen with two or more participants goes on the fix list. If you're not sure whether to test or audit first, see UX audit vs usability testing. If you'd like the testing run for you, that's my usability testing service.
Questions people ask
What should a usability testing script include?
An introduction, consent to record, a warm-up, three to five scenario tasks read word for word, a question after each task, and a wrap-up. Each task should have written success and failure criteria.
How many tasks should a usability test have?
Three to five for a 45 to 60 minute session. Beyond that, participants tire and the later tasks produce weaker data.
What are good usability testing questions?
Open, neutral ones: "What are you looking for?", "What did you expect that to do?", "What do you think happened?". Avoid questions that name UI elements or suggest an answer.
Can I use this script for unmoderated tests?
Yes, with changes. Write the scenarios as on-screen text, replace live prompts with a written question after each task, and add a question asking participants to describe the outcome in their own words.
Sources
- Thinking Aloud: The #1 Usability Tool, Nielsen Norman Group
- Task Scenarios for Usability Testing, Nielsen Norman Group
- Talking with Users in a Usability Test, Nielsen Norman Group
- 10 Things To Know About The Single Ease Question (SEQ), MeasuringU
Working on this?
Tell me what you're building and where it's stuck: book a 30-minute call, email work@utkarshdesign.com or send a brief.