Usability Test Script: Writing Tasks That Don't Give Clues

What goes into a script?

Lyssna proposes a five-block structure, which is also the most common one:

1. Introduction and consent. Welcome, an explanation of the goal, permission to record, and how the data will be used.
2. Context questions. Things about the person that help you interpret what they do: how they use similar products, how often.
3. Tasks and scenarios. The core of the session.
4. Follow-up questions. To understand what the person saw, thought, or expected.
5. Close. Wrap-up questions, thanks, the person’s questions, and if relevant, a short satisfaction survey.

Lyssna’s template allocates five minutes to the introduction, five to warm-up questions, ten to wrap-up questions, and two to the closing, and recommends keeping sessions to 30 minutes at most. That leaves about eight minutes for the tasks, and the guide recommends three to five tasks per session (Lyssna, “Usability test script”).

Why should a designer care?

Because the task is what changes the result most. A badly written task tells you more about your wording than about your design: if the person finds the button, it’s because the task told them what it was called.

Writing the script also forces you to decide what matters. If you can’t write a concrete task for a feature, you probably don’t yet know what that feature is for.

How do you write a good task?

NN/g sums up three rules: the task should be realistic, actionable, and free of clues (NN/g, “Task scenarios for usability testing”). In practice:

• Describe the goal, not the path. If the button is labeled “Workspace settings”, don’t put those words in the task. Write something like “You want your colleague to be able to see your projects”.
• Use the person’s language. If the interface says “Billing” and the person looks for “getting paid by my clients”, the task should say the second.
• Give all the information needed. Date, budget, or recipient. A vague task produces vague answers.
• Ask for the action, not the explanation. “Place the order” rather than “How would you buy this?”.
• One task, one sentence. If you need three sentences to explain a task, it’s probably three tasks.

NN/g puts it in a sentence worth keeping close: give the participant all the information they need to complete a task, without telling them where to click (NN/g, “Task scenarios for usability testing”).

Userbrain adds that the wording should not reveal the “right path” or ask for opinions or predictions about future use, but ask about concrete behavior (Userbrain, “How to write effective tasks”).

What do you say when someone gets stuck?

This is the hardest moment for a moderator. The rule is not to give clues. Lyssna suggests neutral think-aloud questions such as “What are you looking for?” or “What would you do next?”, and warns against pointing to where to click, because the goal is to check whether the user can discover the feature on their own (Lyssna).

If the person stays stuck for a long time, give them the information they need to continue with the task, and note that they got stuck. That moment is as valuable a data point as an error.

Example

Illustrative example: a script for a medical scheduling app includes the task “You need to move your Thursday afternoon appointment to next week, because your son has a fever.” The first version said “Reschedule your appointment using the appointment management menu”. In the first session, three of five people looked straight for that menu without reading the screen. After rewriting the task without those words, two of five got lost on the history screen, which was the real problem. The new task gave the team the data it needed.

When NOT to use a closed script

• In exploratory interviews. If you’re trying to understand a problem, a rigid script stops you from following what the person says. A user interview with topics, not tasks, fits better.
• When the task depends on the person. If the test needs real data from someone’s life, an invented task can feel unrealistic. Adapt the scenario in advance.
• If the goal is to measure one thing. A first-impression test doesn’t need tasks. Use a five-second test.

Common mistakes

• Using the name of the button or section in the task.
• Writing tasks that end with “and tell me if you like it”.
• Giving clues when someone gets stuck, even without meaning to.
• Reusing the same tasks after the product has changed.
• Going into a session without having piloted the script with a colleague.

How to start tomorrow

Take the most important feature of your product and write three tasks without using any word from the interface. For each one, define what counts as success. Pilot the script with a colleague from your team, not someone who knows the product, and fix any sentence that gives clues. Then, when you have sessions, calculate the usability metrics for each task. If you don’t yet know whom to invite, the piece on recruiting participants helps you decide.

Sources

• NN/g: Task scenarios for usability testing
• Userbrain: How to write effective tasks for usability testing
• Lyssna: Usability test script