How to write usability test tasks: so people search, not guess
A test is only as good as its tasks. One word from the menu, and people stop searching and just spot the button with the same label. How to write tasks that measure what you mean to measure.
The Tack team··6 min read
Short answer
A good task describes a goal, not a path. Instead of “Click Pricing”, write “Find out what the app would cost you per month”. It avoids words from the interface, gives a short reason why the person is doing it, and has a clear end you can use to tell it is complete.
Put one to three tasks in a test, easiest first, each independent of the others. Try them on one person before you send them out.
On this page
Why the wording matters so much
A usability test measures whether people find their own way. When the task gives the way away, you only measure whether they can read. “Add the product to your favourites” on a site with a Favourites button is a task nearly everyone completes, even if they would never have found the feature otherwise.
In an unmoderated test this matters even more. Nobody clears up a misunderstanding, nobody explains what you meant. The task has to stand on its own.
Six rules of a good task
- A goal, not a path. Describe what the person wants to achieve, not where to click. Let them find the way.
- No words from the interface. When the button says Plans, write “what it costs” in the task. Otherwise people just look for the matching word.
- A short reason. One sentence of context helps: “You want to use the app with your colleagues.” People skip a longer story or search it for hints.
- Concrete details. “For a team of five”, “a flight to Rome for the first weekend in May”. With concrete details people act like real customers, not testers.
- One goal and a clear end. The person has to know when they are done, and you have to be able to tell it worked.
- Short. People read the task in a small panel at the edge of the page. One or two sentences are enough.
Examples: bad and better
| Bad | Better |
|---|---|
| Click Pricing and find the Pro plan. | You want to use the app with four colleagues. Find out what you would pay per month. |
| Explore the app. | Find out whether the app can export to Excel. |
| Use the Price filter to find the cheapest flight. | You want to fly to Rome for the first weekend in May as cheaply as possible. Find a flight you would buy. |
| Do you like the home page? | Look at the home page. Who do you think this app is for? |
| Sign up, set up your profile and invite a colleague. | Three separate tasks, each with its own end. |
Note the last two rows. “Do you like it?” measures politeness, not behaviour. And a task with three goals has no clear end: when someone stops at the second step, you cannot tell whether they failed or just did not finish reading.
How to tell a task is complete
For each task, write down an end you can check. In a real app, such as a prototype built with AI, Tack detects it on its own:
- A page address: the person reaches
/order/done. - A click on an element: they click a plan’s button or a search result.
- A custom event: the app sends
window.tack.track('export_done')when the export really works.
A custom event helps when several paths lead to the goal, or when success does not show in the address. For tasks like “Find out what you would pay”, you can count a click on a plan as success and ask after the task what price the person found.
One difficulty question after each task is worth it (SEQ). When the score is low, ask openly what was hard. The answers tell you why; the numbers only tell you how many.
How many tasks, and in what order
- One to three tasks. An unmoderated test should take about five minutes. People finish longer tests more superficially, or not at all.
- Easiest first. The first task is also a warm-up. When people fail right at the start, they often give up on the whole test.
- Independent of each other. When the second task needs the result of the first, failing the first ruins both.
- Try it on one person. A pilot catches an unclear task before the next five people see it.
For how many people you need, see How many people you need for a usability test.
FAQ
How do I write a usability test task?
Describe a goal, not a path, and avoid words from the interface. Add one sentence of context, concrete details and a clear end you can use to tell the task is complete. For example: You want to use the app with four colleagues. Find out what you would pay per month.
How many tasks should a usability test have?
For an unmoderated test, one to three tasks, so the whole test takes about five minutes. Order them easiest first and so that they do not depend on each other.
What is the difference between a task and a scenario?
A scenario is the short context of why the person is doing the task, such as wanting to use the app with colleagues. The task is the concrete goal they complete in that context, such as finding the monthly price. A good brief has both in one or two sentences.
Can I ask in a test whether people like the page?
You can, but the answer tells you little, because people tend to be polite. It is more useful to give them a task, measure whether they managed it, and then ask what was hard.