Task authoring
Write usability test tasks that do not reveal the answer
UxerProof Editorial · · 3 min read
If a task tells the tester every menu label and button to choose, it can verify a prescribed sequence. It is less useful for finding out whether the interface makes that sequence discoverable.
Good task wording gives enough context to attempt a meaningful outcome while leaving the navigation to the person or simulated participant. The distinction matters because the instructions themselves can otherwise conceal the problem you hoped to investigate.
Separate the goal from the route
Compare these illustrative instructions:
| Guided instruction | Goal-based task |
|---|---|
| Open Reports, choose Weekly and click Export. | Prepare a copy of this week's activity to share with your manager. |
| Click the filter icon and select Archived. | Find the project you finished last month. |
| Open Settings and select Team. | Find out who currently has access to this workspace. |
The goal-based versions still need appropriate setup. The tester should have the intended role and safe records that make the task possible. Avoid turning a usability review into a guessing game about facts the interface cannot provide.
Add realistic context without invented personality
Useful context describes constraints: a first visit, an existing draft, a need to avoid sending a real message or a requirement to use a particular input method. It does not need a long fictional biography.
Do not treat a persona label as proof that a synthetic participant represents a demographic group. A configured behavior is a test condition. Questions about actual language, expectations or circumstances need appropriate human research.
For human sessions, GOV.UK recommends clear and believable tasks that do not give away the route to completion. That guidance supports task authoring; it does not validate simulated behavior as a substitute for participants. GOV.UK guidance on designing tasks.
Keep success criteria outside the prompt when needed
The reviewer may need a precise finish line that the participant does not see. For example, success could require a saved report covering the intended date range. The task can ask for the report without prescribing where the date selector lives.
Write both pieces down: the participant-facing task and the reviewer-facing acceptance criteria. This prevents a later argument about whether an attractive but incorrect output counts as completion.
Pilot the wording
Try the task with a colleague who did not write it. Ask whether the scenario is understandable, whether required information is missing and whether the wording accidentally teaches the navigation.
If you change the wording between runs, record the change. A clearer task prompt can improve completion without any product improvement. Preserving the prompt version helps you distinguish those explanations when comparing evidence.
Next step: Put the final task and acceptance criteria into a Golden Journey Test Contract.
Put the evidence structure to work
Inspect UxerProof's fictional sample report, or use the free readiness check to prepare your next journey. External Circuit execution is not yet activated; see current launch status for availability.