A prototype is an instrument for producing specific evidence, not a validation result in itself. Before building it, agree which assumption it tests, who can provide relevant evidence and what outcome warrants proceeding or revising. Designing polished screens and then searching for positive interpretations of feedback reverses that order.
Someone may understand the concept without needing it, need it without being able to use it, or use it competently without controlling the purchase. These are different findings. A test brief should state which question it addresses and which questions will remain open afterward.
Separate the assumptions hidden inside a demonstration
The first concerns understanding: does the participant know what the product offers and what its states mean? The second concerns workflow fit: does it support a real task within that person’s authority and constraints? The third concerns commercial behaviour: is there willingness and ability to take an appropriate purchasing or operational-trial step?
A prototype can inform the first two without resolving the third. Do not convert praise into commitment or task completion into proof that a market will pay. Product Validation starts with an explicit assumption, a suitable experiment and an agreed decision criterion.
Strategyzer’s Test Card connects an assumption with a test, measure and success threshold. Test Card reference. Use that logic without assuming a universal threshold applies to every product.
Match prototype fidelity to the evidence needed
A simple flow may be sufficient for a question about work sequence. Understanding mobile notifications may require more realistic content, sizing and interactions. More detail does not repair an unclear question and may invite discussion of colours that are irrelevant to the decision.
Within Mobile App Design, the prototype should support a defined scope and relevant contextual states. Do not imply that live synchronization or an intelligent algorithm is operating when the behaviour is simulated. Explain the prototype’s limits without revealing how to complete the task being tested.
Document what the prototype intentionally leaves out. A polished screen can make a concept appear operationally complete even when no source system, permissions or recovery behaviour has been investigated. That impression should not become an assumption in the next development estimate.
Worked hypothetical example: coordinating deliveries
This is an instructional scenario, not a real project result. A team is investigating a mobile screen that helps dispatch supervisors review delayed requests and reassign them. Its main assumption is that supervisors can understand why a request is prioritized and make a correct decision without losing the current assignment context.
Before sessions, the team sets a decision rule: proceed to a bounded technical experiment only if no material misunderstanding of assignment state remains and the task can be completed without designer explanation. If supervisors lack authority to reassign work, stop this route and investigate the role again. These are local rules for the fictional example, not universal success criteria.
| Evidence type | What the team records | What it cannot establish |
|---|---|---|
| State understanding | How the participant explains “delayed” and “reassigned” | Daily adoption |
| Task performance | Independent completion, assistance or incorrect action | Live technical functioning |
| Role fit | Who approves reassignment in current work | Identical operations across all organizations |
| Commercial interest | A specific permitted next step | A purchase contract or guaranteed demand |
Suppose six supervisors join an exploratory round: four complete independently, two need explanation, and one of the six believes reassignment leaves the original task unaffected. “Most succeeded” is an inadequate summary. The state misunderstanding triggers the revision rule despite four independent completions.
The decision is to clarify assignment behaviour and retest that part. Actual integration with the existing system and commercial demand remain untested. User Research can document what was observed, what participants reported and the limits of the round without turning six sessions into a market-prevalence percentage.
A useful report would also identify whether the misunderstanding arose from terminology, omitted context or a genuine operational disagreement. Those explanations imply different responses. Renaming a label may not help if supervisors disagree about who is authorized to change an assignment.
Protect the test from a moving target
Save the test plan before execution. If tasks, participants or the prototype change, record the reason, new version and implications for comparison. Do not pool results from materially different versions into one number without explanation. Do not lower the threshold because the team has become attached to the design.
Allow “inconclusive” as an outcome. Recruitment may not fit, the simulation may be insufficient, or data may be unclear. Specify the missing evidence rather than writing “initially validated” to make the report more reassuring. Operational constraints can also justify pausing a promising idea.
Assign the decision owner in advance. Researchers provide evidence and interpretation; the sponsor must decide what commitment follows. If no one can authorize a change or stop, the study risks becoming a demonstration with no consequence.
Define what moves into development
Carry forward approved decisions: the role, priority journey, state rules, discovered constraints and unresolved questions. Product Discovery & Requirements can turn them into scope and acceptance criteria. The prototype alone is not a complete specification; it may omit permissions, lost connectivity or duplicate-action handling.
Concept-test acceptance checks:
- Assumptions are distinguishable from the proposed solution.
- Proceed, revise and stop rules were documented before testing.
- Simulation limits and untested areas remain explicit.
- Behaviour, opinions and team interpretation are separate.
- The report names a decision and owner, not just “positive feedback.”
- No commercial-success promise or production-readiness claim is attached to the demo.
Frequently asked questions
Do we need a high-fidelity prototype?
Only when the assumption requires it. Use the lowest fidelity that can produce valid evidence, without simplifying away the very issue under investigation.
Should success criteria be numerical?
They can be if appropriate to the question and method. Justify them and connect them to a decision rather than borrowing a popular percentage and treating a small sample as statistical proof.
What should we do with positive comments?
Keep them as contextual opinions, not commitments or task-performance evidence. Explore past behaviour or experience when a stronger explanation is needed.
Does revision mean the project failed?
No. It may prevent a larger commitment to an unclear solution. The useful measure is what the team learned and which decision changed, not whether the first design survived.
Commission a test with an explicit decision, and establish a decision sponsor and relevant participants before investing in prototype detail.
Source
- Strategyzer: Validate your ideas with the Test Card. Example numbers and decision rules are fictional and specific to this scenario.
