Buy the prototype that helps you make a decision, rather than the one that looks most impressive in a presentation. A wireframe may settle an information-order question. A clickable prototype may reveal whether someone understands a task sequence. Uncertainty about connecting to an external system or processing a real file requires a bounded technical experiment, not polished transitions between screens.
Problems arise when the parties use “prototype” to mean different things. The buyer expects launchable software, the designer means a simulation and the engineer means temporary code answering a technical question. Defining the question, deliverable and usage limits before pricing prevents that mismatch.
Match fidelity to the unknown
| Deliverable | Useful question | What it does not establish alone |
|---|---|---|
| Wireframe | Are essential information and steps organised clearly? | Final appearance or actual system behavior |
| Clickable prototype | Does someone understand choices and transitions? | Server integration, persistence or production capacity |
| Bounded coded proof | Does a technical assumption work under specified conditions? | Complete product quality, security or operations |
These are suggested purchasing distinctions, not mandatory terminology for every supplier. Ask for an operational definition in the proposal. Which elements are interactive? What data is used? Are connections real? Does a facilitator simulate any behavior? Proposals become comparable when those details are visible.
Mobile App Design can represent the agreed journeys. User Interface Design can specify components and states when the question concerns visible interaction. Neither means that development is automatically included in a design file.
Worked hypothetical: a field-service product
Imagine a product that shows a technician a daily assignment, provides instructions and allows a photo attachment and status update. The team has three uncertainties: where the technician should find the assignment, whether “visit completed” and “request closed” are understood differently, and whether a legacy system will accept an update from the new interface. This is an educational scenario, not a client case study.
The team begins with a simple assignment-list and detail-page wireframe. If site instructions matter before administrative reference numbers, the information order can change without reworking a finished visual design. Once the structure is stable, a clickable prototype illustrates visiting, closing and correcting an accidental selection. Test data is explicitly fictional, and participants know that photos are not being transmitted to a live system.
The integration question goes to an engineer working in an authorised test environment. The coded proof is bounded to updating one test request through the available interface and recording both the response and an expected failure. If credentials or integration documentation are unavailable, feasibility remains unresolved. A simulated success message must not be presented as a working connection.
The experiment might establish that the screen structure is understandable while the integration requires a change by the legacy-system owner. The resulting decision is to separate design approval from commitment to a full build and make that external dependency visible in the proposal.
The team also decides what happens to the experimental code. It may be discarded, or reviewed before reuse. A single successful run is not a reason to place it in production. The handoff should explain shortcuts and assumptions so another engineer does not mistake a temporary proof for a supported foundation.
Write a small agreement for each artifact
The brief should answer six questions: the decision to be made, the user and task, included paths, data and dependencies, evaluation method and explicit exclusions. Add a stopping rule. Has the information structure become clear? Does a consequential misunderstanding remain? Did the technical attempt work in the named environment?
GOV.UK’s user-story guidance connects the user’s goal with inspectable acceptance criteria. Use that principle without importing a government process wholesale. Writing user stories. “The technician can tell whether the request is actually closed” is more useful than “deliver a professional status page”.
Where the decision concerns a product assumption, Product Validation can scope a focused experiment. Understanding a prototype does not, by itself, establish willingness to pay. That commercial question requires different evidence. Where the uncertainty is technical, specify the App Development contribution, test environment and permissions explicitly.
Agree how changes will be handled, too. Discovering a new business rule is not necessarily a small visual revision. Record whether it changes the research question, the prototype’s paths or the eventual build scope. The point is to learn efficiently without allowing every new idea to enter the same fixed-price deliverable.
Acceptance checklist
- The recipient can open the files, and agreed ownership and access are in place.
- Interactive paths are distinguishable from decorative or disconnected screens.
- Real and simulated behavior is documented, including fake notifications or confirmations.
- Unresolved assumptions have decision owners rather than remaining scattered in comments.
- Findings answer the original question and identify what was not tested.
- The next-step recommendation has a rationale rather than automatically proposing a full build.
Common mistakes include paying for final visual detail before settling structure and asking a simple prototype to simulate every possibility. The opposite mistake is treating a polished mockup as a complete implementation specification. Permissions, errors, concurrent activity and data handling may still be undefined. Record those gaps before engineering handoff so they do not become contractual surprises.
Frequently asked questions
Does a clickable prototype replace requirements?
No. It illustrates part of the experience, while business rules, dependencies and exceptions need complementary documentation. That documentation can be concise if the links and acceptance criteria are clear.
Does every project need all three levels?
No. Choose the artifact that resolves the important unknown. The structure may already be settled with only a technical question outstanding, or the system may already work and need a layout test.
Is a coded proof ready to launch?
Do not assume so. Quality, security, data handling, operations and testing need a separate build assessment before experimental code is used in a live product.
Who approves moving forward?
A named client decision owner, supported by design or engineering according to the question. They should review evidence and limits, not presentation polish alone.
Before requesting a proposal, write the three most important unknowns. For each, choose the smallest deliverable that supplies appropriate evidence. That is more valuable than a large prototype that leaves the real decision unresolved.
Source
- GOV.UK: Writing user stories and acceptance criteria, reviewed 26 October 2026.
