Research intermediate: plan a prototype test
Turn a hypothesis into an observable task and distinguish independent success from assisted completion.
About 15 min readingAs of Oct 2026
By the end of this guide
- Write a task without route clues.
- Record behaviour and help separately.
- Bound the conclusions of a study.
Who this is for
- People learning to structure this work with AI
- People who want to check a draft against evidence
What you need
- All cases, records and numbers here are fictional teaching material, not recorded model replies or research findings.
- Paper and a pen are enough. To try a prompt, use an assistant you already have and only the fictional material.
This lesson’s terms, in plain language
Read the short meanings here. Open a term for a fuller explanation and example.
- prototype
- A model used to investigate an interface or flow before a finished product.
- hypothesis
- An unverified idea that can be investigated through observation or a test.
Key ideas
Choose the behaviour to investigate
Figure: Observe a prototype with a small completion indicator and one with a link to the record. · AI Ping Two fictional prototypes differ after saving: A has a small indicator; B includes a link to the saved record. Instead of asking which looks better, investigate whether people recognise completion and retrieve the record.
The eye in the drawing means observing use, not asking AI for a design score. A prototype is a model for testing a flow before the finished product. Document any non-working parts.
“Clearer feedback will make retrieval easier” is a hypothesis, not a result. This lesson produces a research plan and interpretation rules. It requires neither buying a tool nor recruiting participants.
Do not reveal the route in the task
“Click Save, then the link below” tests following instructions, not discovering the route. Try “Record today’s reading, then find the record you just made.” Match the task to the research question.
Use a fictional book and note so the practice does not require personal reading history. Real studies also need appropriate recruitment, consent and data handling; this exercise focuses on task wording.
Underline button names, positions and suggested routes. Remove clues that solve the task for the participant. AI can flag wording, but its approval does not prove that real participants understand the task.
Record completion, help and difficulty consistently
Figure: Left to right: independent completion, assisted completion, incomplete. Separate outcome from assistance. · AI Ping Use three practice statuses: independent completion, completion after help, and incomplete. Record exactly what help was given. These categories are an exercise convention, not a universal scoring system.
The second drawing distinguishes a check, assisted progress and an empty outcome. Someone might find the record accidentally while still missing completion feedback. The route matters as well as the endpoint.
Fictional P1 succeeds independently, P2 succeeds after a location hint, and P3 does not finish. That is one independent and one assisted completion. “Most succeeded easily” would hide the assistance and invent a judgement about ease.
Keep conflicting evidence and limitations
Mark evidence that conflicts with your preferred design. A comment about added clutter belongs in the record with its context. Ask AI to retain contrary and unresolved cases rather than producing a uniformly positive summary.
If someone tries A before B, learning from A may influence performance on B. Faster performance alone does not isolate the design change. Inspect order, conditions and assistance.
A small usability study can uncover specific difficulties without estimating market preference. These three fictional records establish no real product outcome. Report behaviour, possible explanations, remaining questions and limitations together.
Try it: a research plan for the next decision
Write a hypothesis, a task, observable behaviour, a help-recording rule and the scope of your eventual conclusion. “Points to the saved record” is observable; “is satisfied” needs a different question and interpretation method.
Do not invent participation. AI role-play rehearses a task or discussion guide; it is not an observed human session. The drawings here explain the flow and are not screenshots of a study.
Summarise P1–P3 with separate independent, assisted and incomplete counts. Population success is unknown. Ask what help P2 needed and where P3 stopped. Connect these remaining questions to the planning course before deciding what to build next.
Common mistakes
- Do not present fictional cases or AI guesses as customer evidence.
- Do not invent deadlines, results or commitments.
- Explain your decision before polishing its presentation.
Practice
What is wrong with “Click the blue button below to find the record”?
See a suggested answer
It reveals the route. To investigate discovery, give the goal: “Find the record you just made.”
P1 independent, P2 assisted, P3 incomplete: how should this be reported?
See a suggested answer
Report one of each status separately. These are invented practice records, not customer success rates. Investigate the help given and the point of difficulty.
Does faster use of B after trying A prove B is better?
See a suggested answer
Not necessarily. Learning from the first attempt may contribute. Check order, assistance and task conditions before interpreting the difference.
References
- Using moderated usability testing — GOV.UK
- Analyse a research session — GOV.UK
