Writing usability test tasks that actually work
A task that hints at the answer teaches you nothing. Five rules for writing usability test tasks that surface real behaviour.
Most usability tests fail before a single participant joins. Not because the product is unclear, but because the task was. A task that hints at the answer, or that quietly asks for three things at once, produces a session that looks smooth and teaches you nothing.
Write the goal, never the route
A good task names an outcome the participant cares about and stops there. "Book a table for four on Friday evening" is a goal. "Click Reservations, pick a date, then press Confirm" is a route, and a route only proves that people can follow instructions.
The moment your wording contains a label from the interface, you have leaked the solution. Swap it for the plain-language version a visitor would use.
A quick rewrite
- Before: "Use the filter panel to find running shoes under 100 euro."
- After: "You want running shoes and you can spend at most 100 euro. Find a pair you would actually buy."
One task, one decision
Bundled tasks hide where the trouble was. If someone has to register, add an item, and check out in one go, a stall at checkout gets blamed on checkout even when the real damage was done during registration. Split it, and let each step earn its own recording.
Give them a reason, not a script
Context is what makes behaviour real. Two sentences of scenario, a budget, a deadline, a person they are buying for, will get you closer to genuine hesitation than a page of instructions ever will.
Pilot with one person first
Run every task set past a single participant before you open it to the panel. You are not looking for findings yet, you are looking for the sentence that made them ask "wait, what do you mean?". Fix that sentence and the other nineteen sessions get better for free.