Clickable prototype
A clickable prototype is an interactive mock-up of an application's screens, linked together so a user can move through a task as though the software existed. Nothing behind it is real: there is no database and no logic, which is why it can be changed in hours rather than days.
Also known as: Interactive prototype, Clickable wireframe, Clickable mockup, Design prototype
Last reviewed
Why a clickable prototype matters
People cannot reliably review a specification. Read a document describing a screen and you will picture something different from the person who wrote it, and neither of you will notice until the screen exists. Show the same people a prototype they can click through and the disagreements surface immediately.
The economics are the entire argument. Moving a button, resequencing a journey or removing a step costs minutes in a design tool and can cost days once it is built, tested and integrated. A prototype front-loads the arguments to the cheapest possible moment.
How a clickable prototype works
Designers produce the real screens — the actual layout, wording and imagery — and link them so that tapping a control moves to the screen it would move to. The result behaves convincingly enough for someone to attempt a task, while nothing is stored and no calculation happens.
You then put it in front of people and watch them use it, rather than asking their opinion. GOV.UK's user research guidance is a sound free grounding in the difference. On our clickable prototype engagements, the full process from initial planning meetings through to completed professional graphics can be completed within approximately 3 to 4 weeks.
Clickable prototype vs wireframe
A wireframe is a deliberately plain layout sketch: boxes and labels showing what goes where, with no styling. It is useful for arguing about structure without anyone reacting to colour.
A clickable prototype is the next step up. It carries the real visual design and it links screens together, so it tests comprehension and flow rather than just arrangement. The trade-off is that people treat a polished prototype as nearly finished, which is useful for investor and stakeholder conversations and can make it harder to get honest structural criticism.
When you need one
Use a prototype before building anything with a non-obvious journey, anything with several user types, or anything you need to show investors or internal sponsors before committing to a build. It is also the cheapest way to settle an internal disagreement about scope, because it turns an abstract argument into a specific one about a screen you can both see.
The one case where it adds little is a screen so conventional that nobody could misread it — a standard login, a simple contact form. Prototype the parts of the journey that are genuinely yours, and let the familiar parts follow established patterns.
Clickable prototype: common questions
No. It looks real and responds to clicks by moving between screens, but nothing is stored, calculated or sent anywhere. That is what makes it cheap to change, and it is why a prototype answers questions about understanding and flow rather than about whether the thing can be built.
Yes, and it is one of the common reasons to build one, because it carries the real visual design. Be straightforward that it is a prototype. Presenting it as a working product creates expectations about timescales that the actual build will then have to meet.
Usually yes, and it saves money rather than adding cost. A prototype catches comprehension and journey problems in hours; the same problems found in built MVP code cost days to fix. Skipping the prototype to save a fortnight commonly costs more than a fortnight later.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.