A clickable prototype is not a feasibility check
Clickable versus code is a live format debate again — Figma flows on one side, thin Next.js or Swift slices on the other, and a growing pile of AI-generated UIs that look finished before anything persists. The useful split is older than the tools. A clickable prototype answers whether someone understands the path. A feasibility check answers whether the hard seam holds when something is written, refused, or unavailable. We have watched RuleCaddie citation paths, Veto secrecy models, and BuilderHelp field seams get "validated" in a prototype review that never touched a database. The room nodded. The risk stayed open.
Two instruments, two risks
A clickable prototype is a set of linked frames. Tap Book and you land on a confirmation screen. Nothing was reserved. No row changed. No token refreshed. That is enough when the open risk is comprehension: do people find the control, do they understand the sequence, does the language land.
A code prototype — a thin coded probe — is a small deploy with real logic and real or honest fixture data. Tap Book and something is written, or the write is refused with a reason you can inspect. That is the instrument when the open risk is feasibility: can the OCR path refuse garbage, can the offline queue drain, can the agent cite a rule number instead of inventing one.
Those answers do not substitute for each other. Running five usability sessions on hotspots does not retire a seam risk. Shipping a coded spike of the seam does not prove the broader flow reads cleanly. Name which risk is open, then pick the instrument that can close it.
What the click path quietly skips
Empty states, permission denials, slow networks, partial writes, and conflict on sync rarely exist as first-class screens in a clickable. The happy path is linked; the failure modes are footnotes in a comment. Production work lives in those footnotes.
Latency and layout stability are invisible in a canvas. A transition that feels crisp as a hotspot can be an Interaction to Next Paint problem once real lists and images load. You cannot measure that in Figma, and pretending the prototype "felt fast" is not a performance claim.
AI-shaped surfaces make the skip worse. A clickable can show a confident answer panel. It cannot show whether the answer touched a document, a rulebook row, or a tool result. That is evidence-path work — the same category as a coded probe, not a frame link.
When the clickable earns its keep
Use it when the hypothesis is about desire or comprehension. Early RuleCaddie screen language, a checkout step order, a CMS editor layout — if the question is "do they get it," linked frames are the cheap honest tool. Time-box them. Throw them away when the question changes.
Do not stretch a clickable into an MVP label. A discussion artifact that survives three roadmap reviews starts to be treated as proof the product works. Stakeholders remember the smooth path. Engineers inherit the missing states.
If someone asks to "just wire real data into the prototype," stop and choose a side. Bolting sheets and plugins onto a canvas creates a messy half-app without the discipline of a coded probe. Either stay throwaway, or open a repo with a kill criterion and a seam in scope.
What a feasibility probe has to touch
Write the claim before the first commit: which seam must hold, what failure would kill the idea, what evidence counts. For Veto that meant secrecy living in Postgres, not in UI that only looked private. For RuleCaddie it meant citations that could be checked against rule numbers. A clickable cannot close those cards.
Deploy the probe somewhere a reviewer who is not on your laptop can hit it. A local demo of feasibility is still a walkthrough. The coded slice should accept a real action class — create, refuse, sync, cite — and leave an inspectable result.
Keep the surrounding chrome thin. The probe is not a product shell with every nav item linked. It is the risky verb under a short path. That is how you avoid promoting polish into proof while still answering the technical question.
What we ask before we schedule either
What risk is open this week — comprehension or feasibility? If both, sequence them: clickable first only when flow language is still unstable; coded probe first when the seam can kill the bet regardless of how pretty the frames are.
What would falsify the claim? If the answer is "they bounce on step two," schedule frames. If the answer is "the write path cannot be idempotent" or "the model cannot stay grounded," schedule code. If nobody can say, you are not ready to prototype — you are still naming the question.
When the session ends, record which instrument ran and which claim it was allowed to touch. A clickable that "went well" does not move a feasibility card. A coded probe that held does not retire a usability card. Keep the labels honest and the calendar stops confusing a smooth demo with a seam that works.
Questions
- When is a clickable prototype enough?
- When the open risk is desirability or comprehension — can people follow the path and understand the language. It is not enough when the open risk is writes, auth, offline behaviour, grounding, or performance under real data.
- How is this different from a wizard-of-Oz test?
- A wizard uses a human to simulate the system for interaction risk. A clickable uses linked frames with no live system at all. Both can inform mental models. Neither replaces a coded probe of the seam that can fail.
- Can a code prototype become the product?
- Treat keep as authorization to rewrite on clean boundaries, not as permission to ship the spike as the codebase. The probe exists to answer a claim; production inherits the learning, not the shortcuts.
Sources
- Clickable prototype or code prototype? Decision matrix 2026 — Format follows the risk: clickable for comprehension; code for technical feasibility.
- Live-code prototyping and handoff friction — Static hotspots cannot validate latency, stability, or real browser behaviour.
- Related: A higher fidelity is not a better answer
- Related: A wizard behind the curtain is not a coded probe