Test a prototype with a concrete task
A worked document example shows how to set a neutral task and keep observation, interpretation and the next change separate.
A prototype test needs a question that can be examined through behaviour. “Do you like the portal?” offers little direction. A more useful question is whether business customers can find the currently approved delivery terms for their account without directions.
The example below is entirely hypothetical. Its task, documents and trial notes do not come from a customer study that was actually conducted.
Define the model and success beforehand
The example portal contains archived document D-11 and current approved version D-12. The team knows this intended state. Success means finding the current version and explaining why it is correct using the displayed information.
Prepare the prototype so this path can actually be tried. Links and relevant states must support the question. A model without a working document link cannot show whether the full task succeeds.
Set a task without revealing the route
One possible instruction is:
You are preparing an order. Find the currently approved delivery terms for your customer account. Show how you recognise the valid version.
The task names the goal, but no menu items or click sequence. Choose people for whom this work is plausible. Explain the test and the model's nature. Do not demonstrate the route beforehand.
Observe what the person actually does. Record questions and hints from the moderator. Finding a document with help differs from finding it independently.
Separate observation from explanation
The following entries are invented examples of how notes might be analysed.
Assumed observation | Possible interpretation | Next change or check |
|---|---|---|
The person opens the first entry without checking approval status | The status may be overlooked | Make version and approval status clearer, then test again |
The document link does not respond in the model | The prototype does not support the task here | Add the connection or explicitly change the test scope |
The correct document is found only after a hint | Independent completion remains unresolved | Test the revised path again with a neutral task |
“The person does not understand the portal” would already be a broad interpretation. Concrete actions and the exact model version are easier to trace. An unconnected link is initially a test-setup problem, rather than evidence of user error.
Turn the trial into a next step
Decide which uncertainty the change should resolve. Then check the revised version with the same goal, without revealing the solution. Document the people, conditions and model parts covered.
A clickable prototype proves neither real access rights, persistent storage nor production performance. A successful task does not replace standards-based accessibility checks either. The trial can answer specific usability questions; its limits should remain visible in the decision.
Sources
Read more
All articles
Design & UX with ASES
User experience, interfaces and brand presence