Clickable Prototype

A clickable prototype is an interactive set of screens that lets someone try a product flow without requiring the full product to work. Linked screens, buttons, and transitions let you observe whether people know where to go and understand what will happen next.

Use the prototype guide to decide which parts of an experience need to respond realistically and when paper or a working model would better answer your question.

Choose the prototype around your question

Choose a clickable prototype when the question requires people to navigate between screens or respond to an interaction. You do not have to make a paper prototype first. Paper may be enough to investigate labels or screen order; a working model may be necessary when the question concerns actual calculations or system behavior.

Start with the least effort that preserves the conditions needed for your test. Investigate the customer problem through research when that is uncertain, and use a prototype to examine the specific experience or behavior you need to understand.

Building realistic concepts

A clickable prototype lets users attempt a prepared task so you can observe navigation, expectations and misunderstandings. Build the paths and responses needed for that task, and record what is simulated. A successful session does not establish that the underlying business logic or integrations work.

As opposed to Lego- or Paper prototypes, clickable prototypes often feel and act so realistic, that many users in fact are in doubt whether it is a fully functioning product or not. Consider not polishing your prototype too much, making it “ugly” in some cases, to help testers feel confident in giving constructive critique.

As digital prototypes often represent the first concrete take on how a final product could look like, they can be a great tool to get everyone involved in the design process. The short time it takes building a prototype allows designers to iterate quickly and present new solutions after a session of critique. With AI builders, a revised version can often be ready before the next participant arrives. In this way they can help keep the conversation going, so that designers don’t disappear for weeks on end building complicated solutions to problems that perhaps don’t exist.

Benefits of clickable prototypes

Prototyping tools are online, with the option of providing a link for stakeholders to view or comment on your prototype. This allows stakeholders to view and play around with the prototypes remotely. Your client doesn’t need to be in the same room.

A clickable prototype can be visually rough or highly polished. NN/G’s guide to prototype fidelity distinguishes visual detail, interactivity and content. Choose each to suit your question: realistic wording may be essential for a comprehension test even when detailed visual styling is unnecessary.

Creating clickable prototypes with AI

AI-assisted tools can turn a written scenario, existing screens, or a short product brief into an interactive flow. You can explore a design without manually linking every screen, and some tools can generate working code. The extra functionality is useful only if it helps answer your research question.

Choose a tool according to what you need to test:

• Figma Make is useful when you have Figma screens or a design system and want to turn them into an interactive experience.
• Lovable and Bolt.new suit shareable, code-backed web-app prototypes when the flow benefits from realistic forms, states or behavior.
• Claude Artifacts can help you quickly explore a focused interaction directly in a conversation.
• ChatGPT Sites can create lightweight interactive websites and apps where the feature is available; sharing and publishing depend on account, workspace and region.
• Google Stitch is more design-oriented: use it to explore screen concepts and layouts before deciding which interactions need to work.

Prompt for a focused prototype

For example, you might ask an AI tool:

Create a mobile checkout prototype with a cart, delivery details, order review and confirmation screen. Let the participant change the delivery address and return to the cart. Use realistic but fictional prices and order details. Do not connect payments or create real accounts. Clearly mark which actions are simulated.

Try the flow yourself before giving it to participants. Check every clickable element, back-navigation path, error state and piece of copy relevant to the task. AI-generated code and interfaces can contain unanticipated functionality or misleading responses. Keep test data fictional unless there is a documented reason and suitable protection to use real information.

The goal is not to generate the most complete app. It is to create the smallest credible interaction that lets you observe user behavior. If you need to verify real integrations, calculation accuracy or data persistence, consider a working prototype and test those behaviors explicitly.

Clickable prototype example: testing a checkout flow

Illustrative test scenario, not results from a completed user study.

A team is designing checkout for a small online store. Before building payments, it wants to know whether first-time buyers can find delivery information, review an order, and understand the final confirmation.

Test component	Example
Assumption	Customers can find delivery costs and finish the planned checkout steps without help
Prototype	Linked cart, delivery, review, and confirmation screens; a few prepared error states
Participant task	“Buy a notebook for delivery next week. Before completing, check the total price and delivery date”
What to observe	Where participants look for delivery details, navigation mistakes, hesitations, and whether they recognize the final confirmation
Decision	Revise labels, screen order, or confirmation wording before implementing real payment handling

A tool such as Figma Make, Lovable, Claude Artifacts, ChatGPT Sites or Bolt.new can create this flow, but the research question should determine which screens and interactions are needed. A polished or code-backed prototype is not automatically a better test.

How to run a clickable prototype test

1. Choose one decision. For example: “Should delivery costs appear in the cart or only during checkout?”
2. Build the paths required for the task. Make relevant buttons clickable, include a way back, and show believable success and error states. Record which actions are simulated.
3. Write a task, not click-by-click instructions. Ask the person to find a delivery date rather than telling them to click the shipping button.
4. Let the participant act. Observe the first action, unexpected routes, confusion, and points where they stop. Avoid explaining the interface while the person attempts the task.
5. Follow up with neutral questions. Ask what they expected to happen and which information they looked for; do not suggest the answer.
6. Make a decision. Fix misleading states, test another layout, or investigate a different assumption before adding implementation detail.

What should you record?

Use a simple log rather than treating completion time as the only success measure.

Observation	What it might mean	Next action
Participant looks for delivery cost in the cart and cannot find it	The cost appears too late or is labeled unexpectedly	Try showing the total and delivery estimate earlier
Participant cannot tell whether checkout is complete	Confirmation text or state is ambiguous	Test an explicit order confirmation
Participant tries to edit the address from the review screen	The prototype does not support an expected return path	Add and test a way to edit details

These are possible observations, not performance statistics or evidence from an actual experiment. Record the behavior before drawing a conclusion.

Clickable prototype vs. working prototype

A clickable prototype is especially useful for navigation, content clarity, and task flow. It usually uses prearranged screen transitions and does not establish that payments, calculations, data retrieval, or account updates actually work. A working prototype is the better next step when the critical uncertainty concerns real functionality. A paper prototype may be sufficient if you only need to test early screen order or terminology.

A successful clickable-prototype task also does not establish product demand or willingness to pay. See the prototype methods guide for choosing an experiment based on what remains uncertain. Use the Experiment Sheet to define the assumption and the Learning Sheet to capture what happened.

Frequently asked questions about clickable prototypes

What is a clickable prototype?

It is a set of connected interface screens with interactive elements that simulate how someone would move through a proposed product. It can look like a working app without having a real backend.

What should you test in a clickable prototype?

Test whether participants can find information, understand labels, move through a realistic flow, recover from wrong turns, and recognize when a task is complete.

Do you need to write code for a clickable prototype?

Not necessarily. Many design tools can link screens without coding, though coded prototypes can also be clickable. Use the approach that provides the behavior the test requires.

Is a clickable prototype enough to validate a product idea?

It can expose usability problems but cannot by itself prove demand, technical feasibility, or long-term value. Combine it with appropriate customer research or other product experiments.