On this page
An app prototype is a tool for answering a question before committing to a full implementation. It may explore whether people understand a concept, can find an action, can complete a workflow, or can use a particular interaction on a real device. The right prototype is the least elaborate version that can answer the important question credibly.
Do not start by deciding that the prototype must look finished. Visual polish can help when appearance affects the research, but it can also distract from an unresolved journey. A convincing screen may hide the fact that the next step, error state, or operational handoff has not been considered.
State the question in observable terms
“Do people like the app?” is too broad to guide a useful prototype. A more focused question might be whether first-time users can find a saved reservation after returning to the app, or whether they understand the difference between a draft and a submitted request.
Choose the people and context relevant to that question. A flow used occasionally on a phone may require different testing from a staff tool used all day on a large display. Do not assume that a colleague who helped design the feature represents an unfamiliar user.
Write down what would change your decision. If the team will build the same feature regardless of the result, the prototype may be serving presentation rather than learning. That can be a valid purpose, but describe it accurately.
Match fidelity to the uncertainty
Sketches can help compare layout ideas and discuss the order of information. A clickable mockup can explore navigation and wording. A coded prototype may be needed when scrolling, keyboard input, responsive behavior, or assistive technology affects the question.
No level of fidelity is automatically superior. A coded simulation that cannot reproduce the important state may answer less than a carefully facilitated paper exercise. Conversely, static screens cannot establish that a complex interaction works on the actual device.
Spend effort on the behavior being investigated. If the question concerns a recovery path after an interrupted submission, build that path. A beautiful opening screen contributes little if the interruption can only be described verbally.
Include a beginning, an action, and a meaningful finish
Give participants enough context to start without telling them which control to use. The task should describe the goal, not recite the interface labels. Observe how they interpret the information and choose their next action.
Provide an ending that resembles the intended outcome. A confirmation screen should explain what happened and what comes next. If the prototype stops early, tell the participant and record that the remainder was not tested.
Include the relevant return journey when it matters. A person may close the app, follow a notification, or return later to check status. Those transitions often expose assumptions that a single continuous demonstration misses.
Mark simulated behavior clearly
Use fictional data and explain that the prototype is a research or demonstration environment. A participant should not mistake a simulated booking, payment, message, or medical interaction for a real transaction.
List what is simulated for the team as well. Authentication, permissions, persistence, notifications, inventory, and payment handling may all be mocked. The prototype can still provide useful learning, but those simulations do not prove that the production systems work.
Protect access appropriately when sharing an unfinished prototype. Avoid exposing it as a public service that people may rely on. Keep real credentials, private records, and operational secrets out of the demonstration data.
Observe the task without coaching the route
Let the participant try the task in their own way. If they pause or choose an unexpected route, ask a neutral question about what they are thinking rather than pointing them toward the intended button.
Record what happened separately from your interpretation. “The participant returned to the previous screen twice before finding the reservation” is an observation. “The navigation is bad” is a broader conclusion that needs explanation.
When the prototype itself breaks, identify the limitation and help the session continue appropriately. Do not count a technical failure in the research tool as evidence that the participant misunderstood the product.
Test uncertainty, not only the happy path
Choose a few realistic variations that could change the design: missing information, an empty list, a denied permission, an unavailable option, or a failed request. The relevant cases depend on the question and the product's risks.
Avoid overwhelming a participant with every possible failure in one session. A focused task can reveal a specific issue more clearly than a long tour of artificial problems. Separate research questions when the combined session becomes difficult to interpret.
Include people with relevant access needs and use appropriate research methods. A prototype that looks usable to the design team does not establish that it works with different input methods, assistive technologies, or cognitive demands.
Turn findings into a decision
Group observations around the question you started with. Identify what the prototype supported, what it contradicted, and what it could not test. Keep uncertainty visible instead of converting a small research round into a universal claim.
Choose the next action: revise the flow, compare an alternative, investigate a technical constraint, or proceed to implementation with stated requirements. A prototype should reduce uncertainty or expose it more clearly, not simply generate a favorable presentation.
If the design changes, record which finding motivated the change. This helps the team avoid revisiting the same assumption without realizing it has already been tested.
Keep production readiness separate
A successful prototype does not establish security, reliability, scalability, maintainability, or operational support. Production work still needs appropriate implementation, testing, monitoring, and recovery arrangements.
Some prototype code may be reusable after review; some should be replaced. Decide based on its quality and purpose rather than the effort already spent creating it. A quick simulation can be excellent research work and still be unsuitable for live users.
Preserve the useful outcome of the prototype: clearer requirements, observed behavior, and a more informed design decision. That evidence is more valuable than treating a polished demonstration as a finished app.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- GOV.UK Service Manual: Making prototypes Prototype fidelity should match the research need, and prototype code should not be assumed ready for production use.
- GOV.UK Service Manual: Moderated usability testing Research tasks should be realistic and relevant, with observation focused on how participants understand and complete them.