If your team disagrees about whether users understand the next step, an interactive prototype may help before development. If the question is whether an external system exposes particular data, attractive screen transitions will not settle it. A prototype's value depends on the decision it supports.
Before allocating budget, ask the user experience design company to write the question being tested and the result that would change the design. Suitable prototypes range from simple drawings to linked screens or code. Greater visual realism is not an independent goal if it adds nothing to the test.
Turn disagreement into an observable task
In a fictional example, a company plans small storage-space bookings. The team disagrees about presenting size through category names or examples of belongings that fit. A prototype can test how someone selects space for described belongings and understands price and timing before submitting a request.
No actual booking or payment is needed for this test. It does require clear representative content and paths allowing users to return and change choices. If a participant presses an inactive button, the facilitator should distinguish prototype limitations from interface misunderstanding instead of reporting a defect in a product that has not been built.
Four cases for selecting the deliverable
| Question | Potentially suitable output | Outside the inference |
|---|---|---|
| Is the step sequence understandable? | An interactive journey with realistic tasks. | Actual server performance and stability. |
| Are option names clear? | Content alternatives tested with users. | Preferences of every customer in the market. |
| Is keyboard interaction possible? | A prototype supporting the intended interaction. | Accessibility of the entire final application. |
| Is external integration available? | Appropriate technical validation outside the visual prototype. | That a simulated response proves production access. |
This is a sorting tool, not a reason to build advanced prototypes for every idea. A sketch may suffice for an initial sequence discussion; a specific behavior may require realistic interaction. Request an explanation of the selected tool and its representational limits, particularly for screen readers or data entry unsupported by image-based prototypes.
Buy a test plan with the prototype
GOV.UK explains that prototypes help explore and test designs, and that prototype code is not automatically suitable production code. Its moderated testing guide describes observing participants performing tasks. These principles help understand the deliverable; they do not prescribe government tools or fixed session counts and durations for your project.
The proposal should identify participants, why they are relevant, how they will be recruited, the task and the results delivered. Employees viewing a prototype in a meeting are not automatically equivalent to prospective users. Equally, a small sample does not provide statistical proof of the whole product's success.
A short session worksheet you can review
- Research question: does the participant understand space differences and select one suited to the case?
- Task: select storage for described belongings, choose a start date and review the request before submission.
- Test data: known fictional belongings, dates and prices without real customer information.
- Observations: hesitation, backtracking, misunderstanding and requests for assistance.
- Decision rule: which observation requires changing wording, the journey or testing an alternative?
- Evidence limits: who participated, what was not tested and what the prototype could not represent.
Describe the task without revealing its solution. “Click medium space and then confirm” tests instruction-following more than discovering a journey. Agree note-taking, any recording and appropriate permission, and protection for materials that need not be shared outside the relevant team.
Connect observations to specific changes
One participant might select space by its name while another assumes it holds larger belongings. The researcher records events, context and proposed explanations, distinguishing observation from opinion. “The design is easy” is insufficient without showing where the journey succeeded and where intervention was needed.
Ask whether the service includes changing the prototype and retesting the affected point. If a proposed solution adds functionality, review its scope impact before approval. Every personal preference need not become another requirement: examine its effect on the task you are buying.
The development decision needs clear boundaries
After the round, you may accept the journey, change it or defer construction until a fundamental question is clarified. Request the prototype version, findings and decision record, including matters needing separate technical validation. The output can then inform development procurement instead of restarting discussion from unexplained images.
The UI/UX proposal deliverables checklist covers other design work, while Arabic and RTL acceptance addresses specialist implementation concerns. A prototype is worth buying when it leaves a clearer decision, explainable evidence and understood limits.
Sources and preparation
GOV.UK's prototyping guide and moderated usability testing guide were opened on 3 November 2026. The example and decision tools are fictional and editorial. AI assisted preparation with text and source review; no user study is claimed to have been conducted for this article.