6.3.3 Prototyping - Clickable Prototype

In Brief

Description

A clickable prototype is an interactive digital mockup in which static screens are linked through click targets — buttons, links, and hotspots — so a participant can move through a task as if using the real product. It is the highest-fidelity Prototyping variant you can build without code: the interactions are simulated by wiring screens together in a design tool. The fidelity is high enough to support real usability testing, which makes it the primary way to check that a product’s interaction design works before engineering starts.

On the fidelity ladder, it sits one rung above a paper prototype, which needs a human facilitator to simulate the interface, and one rung below a single feature MVP or mash-up, which run on real backends with real data. That position is what lets you observe whether users complete tasks, measure how long they take, and identify where they get lost — without building anything real.

A clickable prototype should not be the first thing you build. If the basic concept and flow have not been validated through paper prototypes, storyboards, or solution interviews, you risk spending days polishing an interaction design for a concept that does not work. A clickable prototype answers “can users use this?” — not “should we build this?” It is not a working product and not a code prototype: there is no backend, database, or real data, and nothing is programmed. A good one covers 1 to 3 core tasks rather than every possible interaction, with unconnected areas showing a “this area is not part of the prototype” message.

Once the concept is validated, reach for one to test detailed interaction design with measurable task-completion metrics, to demonstrate the product to stakeholders, investors, or partners who need to “see it working,” or to test specific interaction patterns such as navigation, onboarding flows, or checkout before engineering invests in building them.

How to

Prep AI Prompt

1. Define the tasks to test. Choose 1 to 3 core tasks that represent the product’s primary value. Each task needs a clear start point and end point — for example, “find a product, add it to cart, and check out” or “create an account and set up a project.”
2. Map the screens. For each task, list every screen the user will see, including error states, empty states, and confirmation screens. A typical task takes 5 to 10 screens.
3. Design the screens. Build each screen in your design tool. Start with the happy path, then add error states and edge cases. Use realistic content — placeholder text like “Lorem ipsum” confuses users and invalidates results. An AI UI generator can produce a first pass from a text description in minutes; treat the output as a draft to refine, not as final.
4. Connect the screens. Add click targets (hotspots) that link screens. Every clickable element either leads somewhere or shows a “not available in this prototype” indicator. Dead clicks frustrate users and corrupt your test data.
5. Pilot the prototype yourself. Walk through every task path twice. Check for dead ends, missing screens, and broken links. Have a colleague test it cold to catch assumptions you missed.
6. Recruit and schedule participants. Recruit 5 to 8 users from the target segment. Match technical comfort level to the real audience — tech-savvy participants navigate prototypes more easily than typical users and will give you a falsely optimistic read.
7. Write the moderator script. Standardize the task introduction, the think-aloud prompt, and your responses to user questions. Decide in advance what you will and will not help with — typically nothing.

Analysis AI Prompt

1. Calculate task-completion rate per task. Percentage of users who complete the task without help. Below 80% indicates a real usability problem; below 50% indicates a flow-level problem that paper would have caught.
2. Plot time on task and first-click accuracy. Large variance between users may indicate inconsistent mental models. First-click accuracy above 70% correlates strongly with overall task success — below that, the call-to-action is wrong, not the task.
3. Cluster the path deviations. When 3 of 5 users click the same wrong button, that is a design defect, not a user defect. Patterns matter more than counts at this sample size — for a sense of the uncertainty in a small-n usability metric like completion rate, ask an AI assistant to estimate a plausible range for the true rate rather than running a pass/fail significance test the sample is too small to support.
4. Synthesize the verbal feedback. Group hesitation moments by screen, by widget, and by task phase. Hesitation that clusters on a screen means the screen is the problem. Hesitation that clusters on a phase (“checkout in general feels off”) means the flow is the problem.
5. Decide the next move. One of three things should happen: tasks pass cleanly → polish the flow and run quantitative validation in Usability Testing; tasks fail at specific decision points → redesign those screens and re-test the affected paths; tasks fail across the board → return to Paper Prototyping and reassess the concept itself.