A prototype test plan sets out, before the first session, which decisive assumption the prototype must confirm or refute, at what fidelity, with how many people and of what profile, which tasks they will do and which result leads to continuing, changing or dropping the idea. Setting the criteria in advance stops the team from reading the result the way it prefers.
How to use
- Write what will be tested and the decisive assumption: what must be true and has not yet been proven.
- Choose the lowest fidelity that answers the assumption, and the session format.
- Set the number and profile of participants, the scenario and 1 to 5 tasks, with the main one first.
- Fix the success and failure criteria and choose the metrics to record.
- Read the warnings, export the plan as PDF or DOCX and the record sheet as CSV.
What each field asks for
| Field | What to enter |
|---|---|
| What will be tested | The prototype in one sentence. |
| Decisive assumption | What must be true for the idea to work and has not yet been proven. |
| Prototype fidelity | Use the lowest one that still answers the assumption. |
| Session format | With someone from the team leading, or the person alone. |
| Number of participants | Qualitative tests usually involve 5 to 8 people per profile. |
| Participant profile | People who actually live the situation, described by behaviour. |
| Session length (optional) | In minutes. Empty: 45. |
| Scenario (optional) | The context the person gets before the tasks, without mentioning the screen. |
| Tasks | From 1 to 5, the first is the main one. State the goal, not where to click. |
| Success: at least how many complete | How many participants must complete the main task unaided to continue. |
| Failure: at most how many complete | At this number or fewer, the idea is dropped in this form. |
| Metrics | What to record for each task. |
Example
A fictional fruit and vegetable box service wants to know whether people who have never subscribed understand the box sizes and choose without asking for help. The plan uses a clickable prototype in 40-minute moderated remote sessions with 6 people who buy fruit and vegetables every week. There are three tasks, and the main one is to choose a box and reach the confirmation. The decision rule is: continue if 5 or 6 complete unaided, change with 3 or 4, and drop with 2 or fewer. The record sheet comes out with 18 rows, one per participant and task.
When to use
- Before testing a prototype with users, so that everyone agrees on what counts as success.
- When the team debates fidelity: the plan shows what each type of prototype can and cannot answer.
- To prepare whoever will run the sessions, with the script, tasks and closing questions ready.
- To record the decision after the test and explain why the idea went ahead, changed or was dropped.
Frequently asked questions
How many participants does a prototype test need?
Qualitative tests usually involve 5 to 8 people per profile: beyond that, problems start to repeat. If there are very different profiles, plan one round for each.
Which fidelity should I choose?
The lowest one that still answers the assumption. Paper suits structure and understanding; clickable, navigation; manual operation behind the interface, testing the value of the output before automating; a service delivered by hand, testing whether the need exists.
Why set the criteria in advance?
Because after seeing the results it is easy to decide that 3 out of 6 was fine. With success and failure fixed beforehand, the result decides, and the discussion is about what to do, not about what the number means.
How do I write a good task?
State the person’s goal in the scenario, not the path on the screen. "Choose the right box for your household" tests the prototype; "click on plans" only tests whether the person can follow instructions.
Is it worth asking whether the person would use the product?
As a metric, it is weak evidence: people tend to answer optimistically. Ask about the past and watch behaviour; if you record intent, use it only as a complement.
What should I do with a result in the middle band?
Fix the failure points that came up most often and test again with new people. If the middle band repeats, go back to the assumption: the problem may lie in the framing, not in the interface.