How to Write Usability Test Tasks That Don't Lead Participants

Why task wording matters

In a usability test, the participant knows nothing about your site except what the task tells them. If the task says "Use the Resources menu to find pricing", you have tested whether people can follow instructions, not whether they can find pricing. The problem you most needed to see, that nobody looks for pricing under Resources, has been hidden by the wording.

The same risk applies to the questions a moderator asks during and after each task. The Nielsen Norman Group defines a leading question as one that "includes or implies the desired answer to the question in the phrasing of the question itself" ¹. Leading questions produce answers that reflect the moderator's assumptions rather than the participant's experience.

From research question to task

Start with what you need to learn, then imagine a realistic situation in which a visitor would do the thing you want to observe.

1. Research question: Can first-time visitors work out which plan suits a small team?
2. Visitor goal: A small business owner wants to choose a plan for five employees.
3. Task: "You run a small office with five people and want to start using this service. Find out which option would suit you and what it would cost each month."

The task gives a reason, a goal and enough detail to make a decision, without mentioning plan names, menus or buttons.

Rules for good tasks

Use the participant's words, not the site's

If the site calls its pricing page "Plans and Packages", do not use either word. Ask what the visitor would ask: "what it would cost". Matching the task to your labels removes the chance to see whether the labels work.

Give a clear end point

The participant should know when they are done. "Explore the site" has no end point; "Find out whether they deliver to your ZIP code" does. A clear end point also lets you record success or failure consistently.

Provide realistic details

If a task requires information, such as an address or an order number, provide it. Participants should not have to invent details or use their own personal data.

Keep tasks independent where possible

If task three depends on completing task two, a failure early on blocks everything after it. Where order matters, plan how the moderator will help a participant continue without revealing the answer.

Avoid sequences that teach the site

Early tasks teach participants where things are. Put the tasks you care about most early, or vary the order between participants.

Before and after examples

The Nielsen Norman Group recommends neutral, open wording for follow-up questions, and advises against naming specific interface elements in questions ¹. "What were you looking for just then?" invites the participant's own account. "Were you looking for the Help link?" plants an answer.

Neutral follow-up prompts

Moderators need a small set of neutral prompts they can use without thinking. These work in most situations:

• "What are you thinking right now?"
• "What did you expect to happen?"
• "Tell me more about that."
• "What would you do next if you were on your own?"
• "How did you decide on that one?"

When a participant asks the moderator a question, such as "Should I click here?", turn it back gently: "What would you do if I were not here?" The goal is to see their natural behavior, not to help them succeed.

Templates you can start from

You do not need to write a test script from scratch. Digital.gov, run by the US General Services Administration, publishes a Usability Starter Kit with templates including a testing script and a recording consent form ². The templates date from between 2013 and 2015, so update the wording for your study, but their structure remains a useful starting point.

For the consent part of the session, see our guide to consent and participant incentives.

Pilot every task

Before the first real session, run the full script with a colleague who has not worked on the site. A pilot catches:

• Tasks that are ambiguous or have more than one reasonable end point.
• Tasks that take far longer than planned.
• Prototype screens that are missing or links that do not work.
• Wording that accidentally hints at the answer.
• Questions that the moderator struggles to ask neutrally.

Fix what the pilot reveals, then lock the tasks. Changing tasks between real sessions makes the results harder to compare.

Tasks for different methods

Moderated sessions allow a moderator to clarify a task if a participant misunderstands it. Unmoderated tests do not, so their tasks must be even clearer, with an explicit end point the participant can recognize on their own. For card sorting and tree testing, tasks are shorter and more uniform, such as "Where would you look to change your delivery address?", because the method compares many participants on the same items. Our information architecture service covers those methods.