Clickable Prototype¶
Software or tool — instantiates Rapid Prototype Learning Loop
An interactive interface shell that simulates navigation or user flow without full backend functionality.
A clickable prototype is a digitally interactive interface shell — linked screens with tappable hotspots, built in a design tool — that a user drives themselves, moving through a simulated flow with no real backend, data, or logic behind the façade. Its defining move is a fidelity inversion: visual and interaction fidelity are pushed high, functional fidelity is exactly zero. Because the user self-navigates with no facilitator playing computer, you get authentic, self-service flow behavior — real taps going where real taps go — and it scales to remote, unmoderated testing. The whole thing is a convincing front with nothing behind it, which is its power and its trap.
Example¶
A regional transit agency is testing a new mobile ticketing flow: buy a day pass, transfer stored credit between cards. Designers wire the screens in a prototyping tool with tappable hotspots — tap "buy," advance to "select pass," tap again, land on a fake confirmation. No payment system, no account backend, nothing real. Test riders open the prototype on their own phones and are asked to "buy a weekend pass."
The click paths tell the story. Most riders first tap the map looking for fares, ignoring the prominent "Buy" button entirely; several abandon at a "select zone" screen they don't understand, because the region recently went flat-fare and zones no longer exist in their heads. The team deletes the zone step and folds fare selection into the map view. The revised flow tests clean the next week. All of this lands before a single backend endpoint is built — with the explicit caveat, stated to every stakeholder, that payment, reliability, and offline behavior remain completely untested.
How it works¶
- Link high-fidelity screens. Assemble realistic screens and connect them with interactive hotspots so the interface responds to taps like the real thing would.
- Hold everything else as façade. No logic, no live data, no real transactions; the prototype simulates the path, not the system.
- Let users self-navigate. Users drive on their own devices, in person or remotely — no human plays computer — so the observed behavior is genuinely self-service.
- Read the click path, then revise. Where taps land, where users stall, and where they drop off are the signal; observed navigation failures drive flow redesigns.
Compared with a Paper Prototype, the interaction here is digital and self-driven rather than hand-swapped by a facilitator, and the higher fidelity makes it remote-testable — at the cost of being slower to change.
Tuning parameters¶
- Visual vs. interaction fidelity — polished pixels, realistic transitions, or both; more fidelity earns credible reactions but deepens the "it's nearly built" illusion.
- Flow breadth — happy path only vs. branching states and error screens; more branches test more but multiply the screens to maintain.
- Moderated vs. unmoderated — a facilitated session yields reasoning, an unmoderated remote test yields scale and less bias.
- Simulated state — how much fake data and conditional behavior is faked in; more state feels real but is laborious and can mask the façade even from the team.
When it helps, and when it misleads¶
Its strength is realistic, self-driven flow evidence gathered cheaply and, when unmoderated, at scale — and it is quick to revise relative to writing code.
Its failure mode is that it is a Potemkin façade: a convincing front with nothing behind it, so it proves nothing about engineering, data integration, latency, error handling, or reliability.[n1] Worse, the very polish that makes it a good comprehension test can convince stakeholders — and even users — that the product is nearly finished, quietly turning a flow test into a false feasibility claim. The guarding discipline is to label loudly what is faked, confine every conclusion to comprehension and navigation, and never let a clickable shell stand in for proof that the thing can actually be built.
How it implements the components¶
test_artifact— the interactive shell that makes a flow navigable and its use observable.prototype_fidelity— a deliberate setting: high visual and interaction fidelity, functional fidelity at zero.feedback_signal— self-driven click paths, drop-off points, and mistaps are the watched evidence.revision_decision— observed navigation failures drive an immediate flow redesign.
It does not implement the moderated-session test_context of the Paper Prototype — users self-navigate, with no facilitator acting as the system — nor the deception safety_or_ethics_guardrail the Wizard-of-Oz Test requires, since a clickable shell hides no human operator and fools no one about what it is.
Related¶
- Instantiates: Rapid Prototype Learning Loop — the clickable prototype is the loop's high-fidelity, self-driven test of an interface flow.
- Consumes: Mockup supplies the resolved screen visuals that are wired together into an interactive flow.
- Sibling mechanisms: Sketch · Mockup · Paper Prototype · Rough Physical Model · Service Walkthrough · Small-Scale Pilot · Wizard-of-Oz Test
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: An interactive interface shell that simulates navigation or user flow without full backend functionality, making its operative form a bounded trial, probe, simulation, or adversarial exercise that generates evidence from performance.
Independent corroboration: The frozen evidence defines Clickable Prototype as 'An interactive interface shell that simulates navigation or user flow without full backend functionality', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Interface, Display & Cue — The interactive shell exists to elicit navigation behavior in a bounded user trial, rather than to serve as a production interface.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Interaction-design practice established linked-screen prototypes that preserve self-directed navigation while omitting backend function.
Review resolution: Both reviewers agree on human_computer_interaction as primary. The source mechanism's defining operation supports that lineage; the reconciled record retains no alternate lineage only where it materially contributes the mechanism, and treats later application breadth separately from origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A Potemkin village is the idiom for an elaborate façade erected to hide the absence of anything behind it — from the (likely apocryphal) story of Grigory Potemkin building fake settlements to impress Catherine the Great. A clickable prototype is a literal one: complete-looking screens with no working system behind them. ↩