Alpha
Proving your concepts
Test the riskiest assumptions by testing your concept for real.
Pre-requisites
- A chosen direction from Discovery
- A named assumption that the prototype must test
What you'll get
- One runnable prototype aimed at your riskiest assumption
- What you learned from putting it in front of people
- Assumptions settled with evidence or sharpened
Build to learn, not to keep
A prototype is not version one of your product. It's an experiment: the cheapest thing that can answer one important question from Discovery — will frontline staff actually use this without training? can the data really move between those two systems? The code is thrown away afterward, whatever the answer. What you keep is the answer.
That's why we agree on the question — and what a "no" would look like — before building anything. A prototype that can only say yes isn't an experiment, it's a demo.
Prototype the risky part, not the easy part
The temptation is to prototype what's straightforward, because it demos well. Resist it. If the risky assumption is whether a two-minute referral flow is possible, build exactly that flow with fake data and put it in front of a handful of real users. Skip logins, admin screens, and polish — they don't help answer the question.
A prototype that disproves an assumption is a success: it just saved you months of building the wrong thing. Many good projects run several of these before committing to a direction — and some discover the right answer is to stop. Cheap lessons are the point.
Further Reading
- - Create, observe, and discard rudimentary solutions to test a concept's viability.
- - Plan tests that observe users completing realistic tasks with a prototype.
- - Define outcomes and benchmarks before testing a design hypothesis.
- - Select an appropriate prototype and avoid treating prototype code as production code.
- - Test the riskiest assumptions with the minimum work needed to learn.
- - Test service concepts with likely users, including users with access needs.
- - Turn assumptions and research questions into a focused research plan.
- - Test whether proposed solutions create measurable public value before full delivery.
- - Start small, gather evidence, and improve services through rapid increments.
- - Apply user-centred testing, small starts, and frequent iteration to public services.
- - Isolates the critical unknowns, learning goals, and concept components that a prototype must test.
- - Builds simple experiments, tests them with real users, and records evidence across repeated iterations.
- - Keeps early concepts feasible while preserving space to test genuinely different approaches.