A prototype gives a design proposal something a presentation cannot: consequences. Someone chooses an option, reaches the next screen and discovers whether the result matches what they had in mind. Prototype testing uses those encounters to investigate a design before the team commits to building the complete product.
The prototype may be a paper sketch, a linked set of screens or working code. What matters is whether it lets a participant attempt the activity the research needs to examine. A beautiful screen that only supports a demonstration can invite useful discussion, but it cannot tell you how someone would find their own way through the service.
Start with the question the prototype must answer
Suppose a fictional bike-sharing service is redesigning how people end a ride. The uncertainty might concern where parking is allowed, whether the bike has locked successfully, or why an extra charge appears. Each question requires different parts of the experience to be believable.
A map and realistic parking instructions may be enough to explore understanding of the rules. Testing whether someone recognises a successful lock requires the relevant feedback and sequence of actions. Investigating trust in a charge requires a plausible amount and explanation. Building every account setting would add work without necessarily improving any of those tests.
This is the practical role of prototype fidelity: choosing which details need to behave or read like the eventual product. Fidelity should follow the uncertainty, not a rule that every project must pass through the same sequence of wireframes and polished screens.
Build enough freedom for a meaningful attempt
The obvious route through a prototype is often the route its designer made clickable. If every alternative is dead, a participant can learn to follow the available hotspots rather than the information on the page. That can make an incomplete design appear easier to navigate than it is.
Include plausible choices around the task, along with the states needed to recognise success or recover from a mistake. Nielsen Norman Group’s account of prototype breadth and depth explains why the amount of the system represented matters to the test. The implication for a team is to inspect the routes a participant might reasonably try, not only the preferred journey.
Use realistic content where content affects the decision. A placeholder account balance, generic error or empty search result can change what a participant does. Test data should be safe to share and sufficiently believable for the activity, without requiring participants to expose private accounts unnecessarily.
Let participants encounter the design
Give participants a task scenario that describes their goal without walking them through the interface. Explain the prototype’s practical limits at the start, but avoid an introductory tour that supplies the knowledge the study is meant to investigate.
In moderated testing, the researcher can acknowledge a missing function and record what the participant expected. In an independent session, the setup needs a clear way to report that problem. Either way, distinguish a limitation of the prototype from a problem with the proposed design. Both can matter, but they call for different action.
If the team works in Figma, Ballpark’s prototype testing provides a way to put those designs into a study. Rehearse the participant’s exact setup before recruitment: a prototype that behaves correctly in the designer’s browser may still have missing permissions or awkward sizing elsewhere.
Make the next version answer the finding
In the bike-sharing example, a participant might correctly park the bike but remain unsure whether the ride has ended. Changing the confirmation message could address that uncertainty; adding a general onboarding tour might never reach the moment when reassurance is needed.
Record what happened, the interpretation behind the proposed change and what a later test should establish. Keep versions identifiable if the prototype changes between sessions, so that findings are attributed to the design people actually saw.
A successful prototype test narrows uncertainty about a design. It does not establish engineering reliability, prove market demand or certify accessibility of the eventual implementation. Those questions need their own evidence as the product develops, including further testing once the interactions are real.