Start with the question, then choose the artifact
A founder asking for an MVP may need to show an investor a product idea. A small business asking for a prototype may need staff to use the tool next Monday. Those requests sound similar but imply different obligations. Before estimating screens or choosing a framework, write down who will use the next version, what they will do, and which decision their response should inform.
Suppose a service business wants customers to request an appointment without a phone call. The first uncertainty might be whether customers understand the available services. It could instead be whether the scheduling system exposes reliable availability. Or the business may already know both and need a working booking flow. Each question points to a different build.
Separate experience, feasibility, and real use
For this guide, a prototype represents an experience well enough to test it; a technical experiment answers a specific engineering question; an MVP is a deliberately limited product that people can actually use to achieve the intended result. The labels matter less than making those boundaries explicit. A polished prototype can contain simulated data, while an unpolished technical experiment can connect to a real integration.
The GOV.UK Service Manual supports using realistic code prototypes to test interactions, while warning against treating prototype code as ready for production. That distinction applies well beyond public services. Visual fidelity tells you little about access controls, data recovery, or operational readiness.
| Build | Question it answers | Useful evidence |
|---|---|---|
| Interactive prototype | Can people understand and complete this journey? | Observed attempts, confusion, and decisions |
| Technical experiment | Can the difficult dependency work? | A reproducible integration or feasibility result |
| Working MVP | Does this limited product deliver value in use? | Completed outcomes, repeat use, and support needs |
Scope one complete outcome
A small product needs an end, not just a beginning. For the booking example, collecting a request is insufficient if nobody receives it or the customer cannot tell whether it succeeded. A useful first release could accept one appointment type, check a single calendar, confirm the result, and give staff a way to correct a mistake. Additional locations and elaborate reporting can wait if they are outside that first promise.
UFAAFU’s digital gifting journey offers a different example of a complete path: create, preview, publish, and let a recipient explore the result. Its interactive cabin can be demonstrated independently in The Lab. That demonstration shows the experience, but the hosted product also needs drafts, media handling, publication records, and recipient access. A beautiful scene alone does not establish that the whole journey works.
Test the dependency that can change the plan
Some uncertainties cannot be resolved by drawing more screens. If your idea depends on a vendor API, test that API with representative inputs before designing every workflow around it. Find out what access is available, whether updates arrive reliably, how errors appear, and what happens when a user repeats an action. Use synthetic or explicitly approved test data rather than casually copying customer records into a demonstration.
For an AI feature, test several realistic examples and difficult counterexamples before treating a single impressive response as evidence. LAYIQ separates search retrieval, preference-based recommendations, and evidence-backed Fit Analysis into different responsibilities. A prototype for a new idea should make the same distinction between the interface being explored and the underlying capability that still needs evaluation.
Ask people to do something, not to approve a design
A useful review gives a participant a plausible situation and watches what happens. Ask the hypothetical customer to find a suitable appointment, change the selection, and recover from an unavailable slot. Avoid explaining every control first. Record where they hesitate, what they expect next, and whether they can explain the outcome. General praise is weaker evidence than successful completion without coaching.
Separate findings about the concept from findings about presentation. Someone may want the service but struggle with a label. Someone may enjoy the interface but have no reason to return. Agree in advance what would justify another iteration, a narrower scope, or stopping the idea. GOV.UK’s agile guidance similarly emphasizes observing real use and changing the service based on what is learned.
Keep the first release small without leaving it incomplete
Once people depend on the product, the team must account for more than the successful demonstration. Identify who can see and change each record, what is stored, how failed requests are handled, and who notices a broken workflow. Include the necessary keyboard access, error messages, deployment configuration, and recovery arrangements in the estimate. These are part of delivering the chosen outcome reliably, even when the feature list is short.
You can still use manual work behind the scenes when it is intentional and manageable. A staff member might review requests before confirmation, for example. Document that step, its owner, and its capacity. Avoid presenting an automated demonstration as a fully automated operating model when a person is quietly doing the essential work.
Give your development partner a decision brief
A practical brief names the audience, current workaround, most important task, unresolved dependency, and next decision. Add the systems the build must connect to, the information it will handle, and what is explicitly outside the first version. Request separate descriptions of prototype work, production engineering, and ongoing operation so the estimate reflects what you are actually buying.
Rapid prototyping is most useful when it changes what gets built next. The deliverable should leave you with a clearer decision: refine the interaction, test a dependency, proceed with a focused product, or stop spending on the wrong assumption.
Sources & further reading
Primary documentation supporting the technical guidance in this article.