Usability test script template with example tasks and session guide

What goes in a usability test script?

A usability test script, which the GOV.UK Service Manual on moderated usability testing calls a discussion guide, holds everything you will say and do in a session, in order. GOV.UK lists three parts: an introduction script, descriptions of each task with any instructions, and a planning checklist. In practice a guide that works also carries warm-up questions, follow-up probes and wrap-up questions, which is the structure the template below follows.

The script protects one thing above all: that every participant gets the same tasks in the same words. GOV.UK puts it as making "sure participants are given tasks in a consistent way". If you rephrase a task on the fly for participant three, you can no longer compare what participant three did with what the other four did. GOV.UK also gives the time budget: sessions "usually take between 30 and 60 minutes", depending on how many tasks you have and how complex they are.

The tasks do most of the work, and they are where most scripts go wrong. Amy Schade of Nielsen Norman Group, in Write Better Qualitative Usability Tasks, states the principle the whole script is built on: "The point of usability testing is to see what users do, not to hear what they would do."

This guide is the second step in a four-part sequence. It assumes you have already recruited with the usability test screener template, and it continues the same example: a grocery delivery app testing a redesigned checkout. If you have not yet planned the test itself, how to run a usability test covers the plan.

What does the full session guide template look like?

Copy this blank guide and fill one per study. Timings assume a 45-minute remote, moderated session with four tasks.

SESSION GUIDE
Study:                         Version:          Date:
Research questions this round:
  1.
  2.
  3.
Prototype or build link:
Test account / dummy data:
Moderator:              Note-taker:            Observers:

0:00  SETUP (2 min)
  Check audio, screen share, recording consent.

0:02  INTRODUCTION (3 min)
  [Introduction script, read as written]

0:05  WARM-UP (5 min)
  W1.
  W2.
  W3.
  Note anything you can use to personalise tasks:

0:10  TASKS (25 min)
  Task 1 (target [x] min)
    Scenario (read aloud, then paste in chat):
    Success looks like:
    Probes after the task:
    Reset before next task:
  Task 2 ...
  Task 3 ...
  Task 4 ...

0:35  WRAP-UP (7 min)
  E1.
  E2.
  E3.
  Observer questions (passed to moderator in chat):

0:42  CLOSE (3 min)
  Thank, explain what happens next, ask how the session felt.

AFTER THE SESSION
  Reset environment checklist:
  Notes saved as: [participant ID]_[date]

What should the introduction script say?

The introduction has four jobs: explain what will happen, tell participants they are not being tested, ask them to think aloud, and be honest about who is watching and what is recorded. GOV.UK advises letting participants know "that you're testing the service, not them", because people arrive nervous about getting things wrong.

On observers and recording, Hoa Loranger of Nielsen Norman Group, in Team Members Behaving Badly During Usability Tests, is direct: do not lie to participants about who is watching. She also notes that Nielsen Norman Group explicitly tells people at the start of each session that they can stop at any time. Here is the introduction for the grocery checkout study, written to be read word for word:

"Thanks for joining. I'm [name], and I work on the team
building this app. For the next 45 minutes I'll ask you to
try a few things on an early version of a grocery checkout.

We're testing the design, not you. If something is confusing,
that's a problem with the design, and it's exactly what we
need to find. You can't do anything wrong today.

While you work, please think out loud: say what you're
looking at, what you're trying to do, and what you expect
to happen. It feels odd at first. If you go quiet, I may
remind you.

I didn't design these screens, so you won't hurt my feelings.
I may not answer questions during the tasks, because I want
to see what you'd do on your own. I'll answer anything at
the end.

Two colleagues are watching on the call with cameras and
microphones off. They'll stay silent, and I'll pass on any
questions they have at the end.

With your permission, we'll record the screen and audio so
the team can review it. The recording stays inside the team
and is deleted after the project. Is that OK?

You can take a break or stop at any time, and you'll still
receive the full thank-you payment.

Any questions before we start?"

If you did design the screens, drop that line rather than say something false. Loranger's advice holds both ways: no lies, including reassuring ones.

Which warm-up questions should you ask?

Warm-up questions do three jobs. They put the participant at ease, they confirm the screener (someone who claims weekly online shopping should be able to describe their last order), and they give you details to personalise the tasks. GOV.UK recommends asking "a few friendly questions to learn more about them" and gives an example of a personalised task: "you told me your daughter is ready for nursery, can you choose a nursery that would be right for her?"

For the grocery study:

• W1. "Tell me about the last time you ordered groceries online. Talk me through it from opening the app to the delivery arriving."
• W2. "What usually goes wrong, if anything, with online grocery orders?"
• W3. "When something you ordered is out of stock, what do you want the shop to do?"
• W4. "Which device do you usually order on, and where are you when you do it?"

W1 is the screener check. W3 gives you the participant's own substitution preference, which you can drop straight into Task 2.

How do you write task scenarios as goals rather than instructions?

Write the goal the person would have in real life, give them the details they need to act, and leave out the route. Marieke McCloskey of Nielsen Norman Group, in Turn User Goals into Task Scenarios, gives three rules: make the task realistic, make it actionable, and avoid giving clues or describing the steps. Her test for a scenario that is too thin is useful in the session itself: "If the task scenario is too vague, the participant will likely ask you for more information or will want to confirm that she is on the right path."

Schade's list of ten task-writing mistakes adds the ones that most often leak the path: using words from the interface, listing the steps a flow will ask for, writing promotional language ("check out the exciting new feature"), and asking "how would you" instead of asking them to do it. Her fix for the first: "Rewrite the task to remove any words that appear in your interface, so you give yourself a fair chance to see if users can find their way around the site."

What do ten task rewrites look like across onboarding, checkout and settings?

Each row below starts with a task that gives away the path, names the leak, and rewrites it as a goal. The products are invented examples.

Flow	Leaky task	What gives the path away	Rewrite as a goal
Onboarding	"Click Get started and create an account with your email."	Names the button and the method	"You've heard this app can plan your weekly meals. Get set up so you can start using it."
Onboarding	"Go through the 4 setup steps and choose your dietary preferences."	Tells them how many steps and what they contain	"You're vegetarian and cook for two. Get the app ready so its suggestions suit you."
Onboarding	"Skip the tutorial and find the home screen."	Assumes a tutorial and that skipping is right	"You want to see what meals the app suggests for this week."
Onboarding	"Connect your calendar using the Integrations tab."	Names the feature and the tab	"You'd like to see your planned meals alongside your work meetings."
Checkout	"Use the delivery slot picker to choose Saturday 9 to 10."	Names the component and hands over the exact choice	"You want this shop to arrive on Saturday morning, before you go out at 11."
Checkout	"Turn off substitutions for bread in the Substitutions section."	Uses the interface label twice	"You don't mind a similar milk if yours is out of stock, but you only want your usual bread. Make sure the order reflects that."
Checkout	"Enter voucher code SAVE10 in the voucher field."	Names the field and calls it a voucher	"A flyer gave you the code SAVE10. Use it on this order."
Settings	"Go to Settings, then Notifications, and turn off marketing emails."	Gives the full menu path	"You're getting too many emails about offers. Stop them, but keep hearing about your deliveries."
Settings	"Use Manage household to add your partner as a member."	Names the feature	"Your partner wants to add things to the weekly order from their own phone. Set that up."
Settings	"Change your default payment card in Wallet."	Names the screen and the outcome	"Your bank sent you a new card. Make sure next week's order is paid with it."

Two patterns run through the rewrites. Every leaky version names a place in the interface, and every rewrite names a reason in the participant's life. The rewrites also carry specifics where the participant needs them (Saturday before 11, the code SAVE10), which follows McCloskey's point that avoiding clues does not mean being vague.

What follow-up probes should you ask after each task?

Ask probes after the task is finished, not during it, and keep them open and neutral. A probe asks about what you saw; it never suggests what the participant should have seen. Write three or four per task in the guide so you are not inventing wording under pressure:

• "What did you expect to happen when you [action you saw]?"
• "You paused on this screen for a while. What were you looking for?"
• "How sure are you that [the goal] is done? What tells you that?"
• "Was anything different from how you'd normally do this?"
• "If you were doing this at home, what would you do next?"

The third probe is the one teams skip and regret. A participant who completes a task but is not sure it worked will phone support or try again in real life, and that is often the most expensive finding in the study. For the moderation technique that sits behind these probes, including what to do when a participant asks you a question mid-task, see how to moderate a usability test.

What should the wrap-up questions cover?

Wrap-up questions collect overall impressions and anything you saw but did not understand. GOV.UK suggests reserving time at the end "to ask follow-up questions about the things you observed but did not clearly understand" and to check for final thoughts. Keep opinion questions here, at the end, where they cannot shape behaviour on the tasks:

• E1. "Thinking about the whole checkout, what stood out, good or bad?"
• E2. "Earlier, on [screen], you [behaviour]. Can you tell me more about that?"
• E3. "Compared with how you order today, what would make you choose one over the other?"
• E4. Observer questions, reworded by the moderator if they are leading.

Then close: thank them, explain what will happen with the research, and ask how the session felt, which GOV.UK suggests so you can improve the next one.

What does a filled session guide look like?

Here is the complete task section for the grocery checkout study, written into the template. The introduction and warm-up are above.

TASKS (25 min)

Task 1: Delivery time (target 5 min)
  Scenario: "This basket is your weekly shop. You want it
  to arrive on Saturday morning, before you go out at 11.
  Get it ordered for then. Don't pay yet; stop when you
  reach the payment screen."
  Success: selects a Saturday slot ending by 11:00, reaches
  payment without help.
  Probes: "How did you decide on that time?" / "How sure
  are you it will arrive before 11?"
  Reset: none.

Task 2: Out-of-stock preferences (target 7 min)
  Scenario: "Earlier you said [their W3 answer]. For this
  order, you don't mind a similar milk if yours is out of
  stock, but you only want your usual bread. Make sure the
  order reflects that."
  Success: milk allows a replacement, bread does not,
  participant can say where they set it.
  Probes: "What do you think happens if the bread is out
  of stock?" / "Where would you check this next week?"
  Reset: none.

Task 3: Discount code (target 5 min)
  Scenario: "A flyer through your door gave you the code
  SAVE10. Use it on this order." (paste code in chat)
  Success: code applied, participant notices the new total.
  Probes: "How much did that save you?" / "What did you
  expect to see after entering it?"
  Reset: remove code from test basket after session.

Task 4: Checking the order (target 6 min)
  Scenario: "You've placed the order. Your plans change and
  you'd now prefer Sunday. Find out whether you can still
  change it, and do it if you can."
  Success: finds order, changes slot or correctly reports
  the cut-off.
  Probes: "How would you know if it had worked?"
  Reset: restore order to Saturday slot, clear history.

If running long: drop Task 3 (lowest priority research
question). Never drop Task 2.

The "if running long" line is worth writing into every guide. Decide in advance which task to cut, so the moderator does not make that call while also watching the participant.

How do you pilot the script before the first participant?

Run the whole guide once, start to finish, with the recording on. Nielsen Norman Group's pilot testing article gives the timing rule: schedule the pilot "at least 1 day in advance of the scheduled study", because you will need to change something. In Schade's words: "Assume there will be changes, because there always are."

A colleague can stand in for the mechanical checks, and GOV.UK suggests exactly that. For the realism of the scenarios, the same NN/g article prefers a pilot participant who matches the target profile, so if you can afford a sixth recruit, use them for the pilot instead. Work through this checklist:

1. Read the introduction aloud and time it. Cut anything over 3 minutes.
2. Open the prototype link from a fresh browser profile, logged out, on the device type participants will use.
3. Run every task without helping. Note any moment the pilot asks "what do you mean?" and rewrite that scenario.
4. Check each scenario against the interface for shared words. Remove any label that appears on screen.
5. Time each task and the whole session. If the total runs over, apply the "if running long" rule now.
6. Test the reset steps between tasks and between sessions, including clearing baskets, codes and order history.
7. Confirm the recording captures screen and audio, and that observers' microphones are muted.
8. Rehearse handing the participant a task in the chat, so dates and codes arrive in the right order.
9. Save the final guide as a new version number, and freeze it for the round.

When should you go off script?

On probes, often. On tasks, almost never. The script fixes task wording so sessions can be compared, but follow-up questions should respond to what you saw, and a guide that is read robotically makes participants guarded. GOV.UK also allows bringing a few extra tasks and choosing "the tasks that are most relevant to the participant", which suits a round where participants differ, such as a mix of phone and laptop shoppers.

The honest limitation is that a script cannot fix a bad task during the session. If a scenario confuses the first real participant despite the pilot, note it, keep the wording for the remaining sessions so they stay comparable, and fix it next round. The report should say which results that task affects. The next step after the script is the session itself: how to moderate a usability test covers think-aloud prompts, when to step in and the observation format, and the usability test report template covers what you send afterwards. If you will analyse recordings with an assistant, AI for usability test analysis explains how to type observed actions into the notes so the analysis has behaviour to work with.

Builders Camp runs live and self-paced bootcamps in product management and AI product building. See the Usability Testing for Product Managers bootcamp for the next cohort and the self-paced version.