A prototype represents a proposed experience so a team can explore how it might work. It can range from a paper sequence to a realistic interactive model.
The central question is what the prototype is meant to establish. A convincing appearance should not be mistaken for a finished, secure or operational product.
What can a prototype test?
It can test understanding, navigation, task sequence or selected interactions. A focused prototype may examine just one important journey.
Choose the uncertainty first. Building an entire interface is unnecessary if the immediate question concerns one decision or control.
Low fidelity versus high fidelity
Lower-fidelity work can make structure and flow easier to change. Higher-fidelity work may be useful when visual detail or realistic behaviour affects the research question.
Neither is inherently superior. More realism also creates more material to maintain and more opportunities for people to assume the demonstration is complete.
What should participants be told?
Explain the context and the task without leading them towards the intended answer. Make clear which parts of the experience are represented.
A prototype can fail to respond because that path was not built. Distinguish that limitation from a genuine usability finding.
How does it differ from a minimum viable product?
A prototype explores assumptions. An MVP is an operational product released with a deliberately limited scope.
A prototype may use simulated data and incomplete paths. An operational release needs appropriate reliability, information handling and support for its actual use.
How should feedback be interpreted?
Observe behaviour as well as comments. A person saying a design looks good does not establish that they can complete the task.
Record what happened and which assumption it informs. Separate a recurring obstacle from an isolated preference.
What happens after testing?
Prioritise findings, revise the experience and test again where meaningful uncertainty remains. Keep track of decisions and their evidence.
The result may be to change the concept substantially. A prototype has still been useful if it reveals that a proposed direction should not proceed.
What belongs in handover?
Explain the intended behaviour, relevant findings and areas not represented. Developers need more than a link to a polished demonstration.
Maintain a distinction between approved requirements and experimental material. That reduces the risk of building incidental prototype behaviour into the final service.
Further reading
For reference, see the supporting documentation. Explore related explanations of Wireframe, User experience, A/B testing.
A practical example
Illustrative example: a venue booking prototype lets organisers compare rooms and request availability. Testing reveals that equipment requirements are unclear. The team revises that step before connecting live booking systems or launching the journey.
Why it matters
Prototypes turn assumptions into something people can examine. Their value lies in the learning and decisions they support before wider implementation.
