Test a Clickable Prototype Before Paying for Code
By CodexierPublished 5 min read
The cheapest moment to discover that users do not understand your product is before it exists. A clickable prototype in Figma looks and behaves enough like the real thing that five people can try to complete real tasks with it, and their confusion tells you what to change while changing is still a matter of moving rectangles. This guide covers what such a test can and cannot prove and how to run one in a week.
What a clickable prototype can prove
A prototype answers questions about comprehension and navigation: do users know what the product is for from the first screen, can they find where to start, do they finish the core task, where do they hesitate, which words do they misread. It cannot answer whether the market wants the product, what price is right or how the system will perform. Those need other methods. Keep the test focused on what it can deliver, and you avoid the trap of a warm reception in the room turning into a cold one at launch.
How realistic it must be
Fidelity is a budget decision. Too rough and testers comment on the drawing instead of the task; too polished and they assume it is finished and stop criticising. The right level depends on what you are testing.
| Fidelity | Use it to test | What to leave rough |
|---|---|---|
| Paper or grey boxes | Information architecture, page order, naming | Everything visual |
| Grey-box with real copy | Comprehension, form flows, onboarding | Colour, imagery, brand |
| Styled Figma prototype | Trust, hierarchy, whether calls to action are noticed | Edge cases, error states, real data |
| Coded prototype | Performance, real data, complex interaction | Only when a click-through genuinely cannot answer the question |
Whatever the level, use real content: real product names, plausible prices, the actual error messages. Testers react to words more than to pixels.
One rule holds at every level: every element that looks clickable must do something, even if it only shows a screen that says this is not part of the test. A dead click makes testers stop trusting the prototype and start guessing about the test instead of about the product.
Test scripts and tasks
Tasks are the heart of the test and the place most first-time tests fail. A task is a goal in the tester's world, not an instruction in your interface. Book a consultation for next Tuesday is a task. Click the blue button and choose a date is a walkthrough.
- Write four to six tasks that together cover the core flow, in order from easiest to hardest.
- Recruit five people who resemble your real users, not colleagues and not friends who know the idea. Offer a gift card for their time.
- Use the same script for everyone: a short introduction, the reminder that you are testing the design and not them, then the tasks one at a time.
- Ask testers to think aloud, and then stay silent. Every hint you give erases a finding.
Sessions run thirty to forty-five minutes over video with screen sharing, or in person. Record with consent, and note that recordings of identifiable people are personal data under GDPR: state the purpose, keep them only as long as the analysis takes, and delete them afterwards.
Reading the results
After five sessions you have a pile of impressions and a strong temptation to remember the ones that confirm what you already thought. Counting protects you from that. For each task and each tester, record whether they completed it, how long it took, and where they hesitated or went wrong. Then group the problems and rank them by how many testers hit them and how badly it stopped them. A problem three out of five people hit on the core task is a design failure; a remark one person made about a colour is a note.
Critical
Stops the task or sends the tester down the wrong path. Fix before anything else, and retest.
Serious
Causes hesitation, backtracking or a wrong first click that the tester recovers from. Fix before development.
Cosmetic
Noticed, commented on, did not affect the task. Log it; fix if cheap.
Deciding what to build
The output of a prototype test is not a list of fixes; it is a decision about scope. Features nobody found or used in the prototype are candidates to cut from the first version. Steps that everybody stumbled on are candidates to redesign before a line of code exists. Run a second round on the revised prototype if the first found critical problems; if the second round is clean on the core task, that is your signal to build. Written down, this becomes the brief the developers receive, with screens that five real people have already completed tasks on.
When you do not need this: a small change inside a product people already use, or a feature so standard that no reasonable design confuses anyone, does not justify a test round. For a new product or a redesigned core flow, prototype testing is built into our product design sprint, and a free call will tell you whether your question is one a prototype can answer. Pricing is on the pricing page.
Frequently asked questions
Why only five testers?
Because the same problems keep appearing after the first few sessions and each additional tester adds less. Five per round, then fix and run five more, finds far more than fifteen in one round on the same broken design.
Can I test with my own staff or friends?
Only as a dry run of the script. They know too much about the idea and want you to succeed, so they solve problems real users would not. Recruit people who match the audience and have never seen the product.
What if testers like the prototype but do not complete the tasks?
Trust the tasks. Politeness makes people say nice things; behaviour shows what they understood. A prototype everyone praises and nobody can use is a failed test with useful findings.
Have a prototype, or an idea that should become one?
Tell us the core task a user must complete. In fifteen minutes we can say what fidelity the prototype needs, sketch the test script and estimate what a round of testing would cost against the code it might save.
Book a free 15-minute call