Clickable Prototype experiment

Tomáš Veselý - podpořen AI
Jun 9
4 min read

We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about product development. Whether you're an inventor, a product manager, or a Chief Product Officer, using the right research methods and experiments increases your chances of building the right things for the right audience. Today we'll introduce the Clickable Prototype validation method.

When to Use This Experiment?

The clickable prototype is a good fit once you already have a sense of how the product should look and work, and you need to verify that users can find their way around it — before a single line of production code is written (for software products).

The rough structure of the prototype's screens is known, for example in the form of wireframes.
You need to test the path through a specific task across multiple screens, not just a single static screen.
The goal is to test navigation, flow, and visual impression all at once.

Basic Experiment Principles

The method comes down to wiring the individual design screens into an environment that behaves like a live product — the user taps a button or makes a gesture and lands on the next screen. That lets you realistically observe how a person completes a given task.

Define the goal of the test. Decide which assumption you're verifying and what task the user should complete (for example, "finish a purchase").
Prepare the screens. Build the key screens for the task in final design, with real content instead of filler text, so testers experience the product's actual flow of information. We often prototype just a single user journey.
Tie the screens together. Define and link the click targets so that one step logically leads to the next and a continuous path through the whole task emerges.
Deliver the test to users. Give 5 to 8 people from the target group a specific task and let them move through the prototype on their own. It pays not to over-polish the prototype — when it looks too finished, people are reluctant to offer criticism.
Collect the data. Track the time it takes to complete the task, the deviation from the ideal path designed by the product team, and qualitative feedback, including the user's reactions. Decision signal: if most testers complete the task on their own, by the optimal path, and without hesitation, the design is ready for development; repeated detours or confusion at the same spot, on the other hand, point to a specific piece to rework. Watch out for the fact that people often say one thing and do another. Behavior decides, not stated preference.
Identify the risks. The method won't verify the technical or performance side of the solution. It answers only the question of clarity and flow of information, not whether the product can actually be built. An over-polished prototype invites falsely positive feedback. Small samples give direction, not statistical certainty. And building a faithful prototype takes time.

Real-World Experiment Example

Link to research: Case Study: Iterative Design and Prototype Testing of the NN/g Homepage

In 2018, the Nielsen Norman Group reworked its own homepage. The team moved quickly from black-and-white wireframes to high-fidelity interactive prototypes, progressively narrowing down a range of visual variants.

Testing ran across three rounds with both new and returning users, on desktop and mobile, and feedback was sorted into four themes: copy, architecture, layout, and visual style. The strongest finding came from a direct comparison of two article layouts: people claimed they liked the grid of squares, but the moment they were also offered a list, they unanimously reached for it. Behavior decided, not stated preference.

The method's key impact was in the ratio of cost to insight: by adjusting designs live during testing, the team gathered more insight in less time and focused its effort only on the layouts with the best response — all before a single line of production code was written, when fixes are cheapest. The resulting design thus rested on real user behavior rather than assumptions, and was rolled out incrementally, page by page.

What Can Be Tested With This Experiment?

The main strength of the clickable prototype is that it surfaces problems with orientation and the flow of information within the product.

Navigation and information architecture: whether a user finds a given feature and understands how to move between screens; the signal is reaching the goal without floundering.
Task completion (task flow): whether the user gets through the whole scenario from start to finish without getting stuck; the signal is completing the optimal path in a reasonable time.
Clarity of interactive elements: whether buttons, forms, and links are intuitive; the signal is the correct first click with no explanation needed.
Preference between visual variants: which of the versions tested side by side people actually use, not which they claim to prefer; the signal is behavior that diverges from the stated opinion.
Feasibility and clarity of the concept before development: whether the solution makes enough sense to the user to be worth building; the signal is behavior matching the assumption recorded in the experiment sheet.
Onboarding and first impression: whether a new user grasps the product's value within the first few screens; the signal is completing onboarding without skipping and correctly naming what the product is for.
Clarity of terminology and labels: whether labels, section names, and buttons match the user's vocabulary; the signal is people clicking in the right place without guessing the meaning.
Priority and visibility of elements: whether the user notices a key action or offer on the screen; the signal is that it draws both the eye and the click without prompting.
Credibility and perceived quality: whether the design feels professional and safe enough (for example, around payments); the signal is willingness to proceed with a sensitive step without hesitation.
Value of a specific feature vs. noise: whether people look for and use a given feature at all, or ignore it; the signal is spontaneous interaction without a nudge from the facilitator.
Willingness to complete a conversion step: whether the user makes it all the way to the final action (sign-up, order); the signal is carrying the scenario through to the end without dropping off at the form.