A clickable prototype before development, and what it settles

Two people in a meeting disagree about how a screen should work. The disagreement is real, neither can prove it, and the usual resolution is that the more senior person wins and the team finds out in month three whether they were right. A clickable prototype before development exists to end that conversation in two days instead, with the thing in front of everyone rather than described.

It is also the step most often skipped, because it looks like the part you could do later. It is not. The cost of changing a decision rises steeply once code, data and a test suite are built on top of it, and a prototype is the cheapest point at which the decision is still cheap.

What a prototype is for, stated narrowly

It is for answering a question you cannot answer by talking. That is the whole scope, and keeping it that narrow is what stops a prototype becoming a slow first version of the product.

The UK Government Digital Service publishes its own standards for this in the open, and its guidance on making prototypes is unusually direct for a government document. It states that you must prototype to explore, share and test different designs before you commit to building anything, and that prototyping lets a team explore ideas faster and at lower risk than working in production code. The reasons it gives are a shared team understanding, better usability, and building the right service rather than building a service right.

Three question types are worth a prototype and most others are not. Whether a flow is understandable without explanation. Whether an interaction that sounds fine in a sentence is tolerable forty times a day. And whether two stakeholders who think they agree actually do.

The code has to be disposable, and this is not a detail

The same guidance is blunt about the other half. It says do not copy prototype code into production, and that the government's own prototype kit must not be used to build live services because it lacks the security and performance features a live service needs. It adds that prototype code does not need to meet production standards, so it need not be secure or handle large traffic.

That permission is the entire source of the speed. A prototype is fast because nobody is writing migrations, handling errors, or thinking about the second user. The moment a prototype is treated as a head start on the real build, it acquires all of that work and stops being quick, and you have a production codebase with none of the foundations and a deadline that assumed it was nearly done.

So the rule we work to: the prototype is thrown away on purpose. If an idea tests well, the guidance suggests working with a developer to clarify the code before others build on it, which is a polite way of saying rewrite it with the decisions you now know are right.

What to prototype, and what to leave alone

Prototype the path a user takes through the thing that is contested. The service manual's phrasing is to use code prototypes to test realistic interactions a user has with your service, and that is the filter: realistic interaction, not every screen.

• The one flow that the business runs on. For a rental operation it is the booking and handover; for a clinic it is the appointment. Everything else can be described.
• Any screen where somebody has said the words it should be obvious. That sentence is a reliable marker for a disagreement nobody has surfaced yet.
• The states that are awkward, not the happy path. The happy path is never the argument. The argument is what happens on a cancellation, a partial payment, or a record that is half filled in.
• Nothing that is already settled. If everyone agrees how login works, a prototype of login buys you no information and costs you a day.

This is the same discipline as deciding what belongs in a requirements document at all, which we set out in the short version of writing one. The test in both cases is whether the artefact changes a decision.

How far to take the fidelity

The guidance names two levels and declines to rank them. Sketches on paper suit exploring and discussing basic ideas with colleagues. Code prototypes are more realistic, can behave like a fully interactive site on mobile and desktop, and suit user research best. Its instruction is to use whichever type best meets your needs at the time.

In practice the choice is decided by audience. A colleague will argue productively with a sketch. A stakeholder who has never built software will read a sketch as unfinished and spend the session on the visual design, so for them the clickable version saves a round. Real users need the clickable one, because what you are testing is whether they can get through it unaided, and that cannot be tested on paper.

One practical warning from the same page, easy to dismiss and expensive when it bites: password-protect anything you publish, so the public does not mistake a prototype for a real service. Internal prototypes get shared outside the team more often than anyone expects.

Where prototypes go wrong

Four failure modes, all of them avoidable and all of them common.

• It gets polished. Somebody adds the real logo and a colour palette, the review becomes about the shade of blue, and the question the prototype existed to answer never gets asked.
• It gets too complete. A prototype covering every screen takes three weeks, which is long enough that the team now has to defend it rather than learn from it.
• It is shown and not tested. Demonstrating a prototype to a room produces agreement. Watching one person use it without help produces information. These are different activities and only the second is research.
• It becomes the estimate. The prototype took four days, so the real thing surely takes a few weeks. The prototype had no data layer, no permissions and no errors, which is most of the work.

On the difference between showing and testing, the same service manual is specific about cadence. Its guidance on how user research improves service design recommends running sessions at least every two weeks, in small batches during every iteration, and says this is more effective and efficient than doing one or two large studies at the beginning or end of development. It also asks team members to watch real users for at least two hours every six weeks. A single prototype demo to a room meets none of that.

That last one connects to the broader pattern in why software projects fail, where the estimate is anchored on the visible part of the work. A prototype makes the visible part look like the whole, which is useful for deciding and misleading for planning.

The honest limits

A prototype will not tell you whether the thing is technically feasible. It is a drawing that responds to clicks, so it can happily depict an integration that does not exist or a response time nothing can deliver. Feasibility questions need a spike against the real system, which is a different piece of work with a different output.

It also will not settle an argument that is really about priorities or budget. If two people disagree about whether a feature is worth building, seeing it working does not resolve that and sometimes hardens it, because now there is something to want. Those belong in scoping, which is the step before anyone writes code, and in the build-versus-buy read in custom software against off the shelf.

And it is not free. Two days of prototyping is two days. On a small, well understood change it is not worth it, and saying so is more useful than pretending every decision needs one. The test is whether anybody in the room is guessing. If nobody is, skip it.