How to Test a Website Prototype Before Committing to Full Development
A prototype test plan for founders: what each fidelity can test, how to write tasks, when to moderate, pitfalls like fake data, and a go/no-go sheet.
How do you test a website prototype before development?
Decide the one or two questions the test must answer, build a prototype just detailed enough to answer them, write three to five realistic tasks that only use paths you have built, and watch about five target users try them, moderated if the prototype is early. Then score each task and make an explicit decision: build, fix and retest, or rethink. The value comes from the decision at the end, not from the prototype.
This guide is for founders and product owners holding a design, or an AI-generated prototype, who want evidence before they commit to a build. It covers running the test. For the general method (recruiting, scripts, metrics and analysis), see our guide to usability testing. This page covers what changes when the thing being tested is not real yet.
Key takeaways
- Match fidelity to the question. Paper can test structure; it cannot test form friction.
- Write tasks only along paths that exist, and seed realistic data.
- Moderate early prototypes. Use unmoderated tools only for functional prototypes and narrow tasks.
- Dead ends, fake data and text fields that do not accept typing are the most common ways a prototype test misleads.
- Polished AI prototypes are useful but can stop a team questioning them.
- End with a written go/no-go decision per task, not a general impression.
Should you build a clickable prototype at all?
Build one when your biggest risk is that people will not find, understand or complete something: navigation, the order of a sign-up flow, whether visitors grasp the offer. Skip it when the risk is elsewhere. If you do not know whether anyone wants the product, test demand with a landing page or pre-sales. If you do not know whether something is technically possible, build a small technical spike. If the site is a familiar pattern (a brochure site, a standard store) with little new interaction, a light wireframe review may be enough.
The wider question of how much design to do, and a decision matrix by type of risk, is in how much UX design to do before development. If you are unsure what separates a wireframe from a prototype, start with wireframing vs prototyping.
Step 1: choose the fidelity your question needs
NN/g defines prototype fidelity as how closely a prototype matches the final system, and notes it varies on three dimensions: interactivity, visuals, and content and commands (Pernice, NN/g). The table below is our planning aid, based on that framing. It sets out what each level can and cannot tell you.
| Prototype type | Can test | Cannot test | Run it |
|---|---|---|---|
| Paper or sketch | Page structure, labels, whether the offer makes sense, flow order | Visual hierarchy, form friction, timing, anything on a real device | Moderated, with a facilitator acting as the "computer" |
| Greyscale clickable wireframe | Navigation and findability, information architecture, step order | Visual appeal, trust signals, real content length | Moderated |
| High-fidelity clickable (for example Figma) | Visual hierarchy, comprehension of real copy, calls to action, first impressions | Typed input and validation, real data edge cases, performance | Moderated, or unmoderated if every task path is built |
| High fidelity with variables and conditions | Simple state: a basket count, a toggled option, branching | Complex logic, free text, real integrations | Either, with a pilot |
| Coded or AI-built prototype | Free input, realistic data, many states, complex interactions | Production performance, security, edge cases nobody built | Either; review the flows yourself first |
| Wizard of Oz (a person fakes the system behind the scenes) | Whether a smart or automated feature is useful before building it | Speed and consistency of the real system | Moderated |
Worth noting
Figma notes that variables and conditional actions in prototypes are available on paid plans, and that a prototype only shows connected frames during playback. Check the current Figma help pages for your plan.
Step 2: write tasks that a prototype can survive
NN/g's task-writing advice applies to any usability test: make the task realistic, make it actionable, and avoid giving clues or describing the steps (McCloskey, NN/g). Prototypes add their own rules:
- Write tasks only along paths you have built. If a reasonable participant could take a different route, build that route or accept you will need to redirect them.
- Define success for each task before the test: the screen or state that counts as done.
- Seed realistic data. Real-looking product names, prices, dates and long names expose layout problems that "Lorem ipsum" and "John Doe" hide.
- If the prototype cannot accept typing, give the values on the task card ("Your postcode is…") and treat form friction as untested.
- For navigation questions, add a first-click question: where would you click first to find X?
- Keep to three to five tasks. Unmoderated sessions in particular should be short.
Task examples: weak versus better
Hypothetical example: a founder is testing a prototype for a booking site for physiotherapy clinics.
| Weak task | Why it fails | Better task |
|---|---|---|
| "Click Book Now and choose a time." | Describes the steps; tests reading, not finding | "Your knee has been sore for a week. Book the first available appointment this Thursday." |
| "Explore the site and tell us what you think." | No success point; the participant wanders into unbuilt pages | "Find out whether this clinic treats sports injuries, then tell me how you knew." |
| "Sign up for an account." | Needs typed input the prototype cannot take | "Create an account using the details on your card. Tell me if anything would stop you." |
Step 3: decide whether to moderate
NN/g says that "early-prototype testing is difficult without a moderator" and that unmoderated studies work best for live sites or highly functional prototypes (Whitenton, NN/g). The practical rule:
- Moderate when the prototype is partial, has unbuilt areas, uses Wizard of Oz, or the question involves understanding or emotion ("would you trust this?").
- Unmoderated is reasonable when every task path is built, tasks are narrow, and the main questions are about finding and completing.
- Always pilot an unmoderated test with one or two people. A Google study of experienced remote participants found that many issues traced back to platforms, study protocols and prototypes, and that participants respond by filing support tickets or simply quitting (Schirra et al., CHI 2023).
- In moderated sessions, agree beforehand how the facilitator will recover a participant who reaches a dead end, so recoveries are consistent and noted.
Step 4: pre-flight checks for prototype pitfalls
Most misleading prototype tests fail for the same few reasons. Run through these before the first session.
- Dead ends: click every hotspot on every task path. Unlinked buttons look like usability problems and waste session time.
- Fake or perfect data: short names, round prices and full stock hide the edge cases real content creates. Add one long name, an out-of-stock item and an empty state.
- Typed input: standard Figma prototypes have long been reported not to accept real typed text. This comes from a long-running Figma community request thread, not an official statement, so check the current tools. Where typing is faked, count form friction as untested and plan to test it in code.
- Device and loading: open the prototype on the device participants will use. A slow load or a desktop frame on a phone becomes the finding.
- Lag: NN/g warns that too long a lag can break the user's flow, so rehearse transitions and any facilitator-driven steps.
- Testing the tool: if participants talk about the prototype viewer's controls, the test is measuring the tool, not your design.
- Personal data: do not load real customer data into a prototype or an AI tool.
AI-generated prototypes: useful, with a polish trap
Tools that generate working prototypes from a prompt change what can be tested early. In September 2026 NN/g wrote that AI tools make it feasible to build fully interactive prototypes of complex interfaces, with realistic data, many states and free input (Chan, NN/g). That removes the typed-input and fake-data limits above.
The same article warns that AI-generated prototypes "may look complete while introducing all sorts of assumptions and inaccuracies", and that their polish "might cause people to stop working to improve it". An earlier NN/g piece found the tools lack the sophistication to weigh design trade-offs and are biased toward mainstream conventions (Wang and Brown, NN/g). Pernice made the same point about any high-fidelity prototype: once a team has invested in a design, it is harder to give up.
Before testing an AI-built prototype, walk every task path yourself, list what the tool assumed (copy, rules, defaults), and decide which of those assumptions the test is meant to challenge. Treat the output as a test material, not as the design.
Step 5: the go/no-go decision sheet
Fill in one row per task after the last session. Severity is your judgement of impact: critical blocks the task or causes a serious mistake; major causes significant delay or confusion; minor is friction most people get past.
| Task | Completed without help (of 5) | Worst severity seen | Was the path fully built? | Decision |
|---|---|---|---|---|
| 1. Find pricing | Build / Fix and retest / Rethink | |||
| 2. Book a first appointment | ||||
| 3. Understand what is included | ||||
| 4. Create an account |
Key takeaway
A simple rule: build when no task shows a critical issue and any major issues have an agreed fix that does not change the flow. Fix and retest when a critical issue appears, or a fix changes the flow. Rethink when participants misunderstand what the product is, because no layout change will fix that. Treat tasks on partly built paths as inconclusive, not as a pass.
Hypothetical example: one round, one decision
Hypothetical example: a founder tests a high-fidelity prototype of a subscription coffee site with five target customers. Four of five find the plans page quickly. Two of five think the "pause anytime" promise applies only after three deliveries, because the copy is ambiguous. Nobody can test the address form because the prototype does not accept typing.
The sheet says: build the navigation as designed; fix the plans copy and retest it with three new people, a short session; and mark the checkout form as untested, to be checked in the first coded build. That is a decision developers can work from, rather than "people liked it".
Limits of prototype testing
A prototype test is a small qualitative study. It finds problems; it does not measure conversion or prove demand. Five users tell you what is broken, not how many customers it affects. It cannot test performance, real integrations, security or how the site behaves with years of content. Do not use it to settle visual taste between stakeholders. And it is not worth running when the design is a well-known pattern with nothing new to learn. Then the time is better spent on content or on a quick test of the live site after launch.
Conclusion and next steps
Pick the question, then the fidelity. Write tasks the prototype can survive, moderate if it is early, check for dead ends and fake data, and finish with a sheet that says build, fix or rethink for each task. Then pass the prototype, findings and the list of faked behaviours to the developers, as covered in our guide to design handoff. If you want help shaping or testing a prototype, ZSpace Labs offers UI/UX design and prototyping.
Want evidence before you sign a build quote?
ZSpace Labs is a remote-first technology studio that works with clients globally on UX design and prototype testing and website development. If useful, we can talk through which flows are worth prototyping and how to test them.
Sources
Nielsen Norman Group: Kara Pernice, UX prototypes: low fidelity vs high fidelity; Kathryn Whitenton, Unmoderated user tests; Marieke McCloskey, Turn user goals into task scenarios; Megan Chan, Test complex interactions earlier with AI prototyping; Huei-Hsin Wang and Megan Brown, AI prototyping in real design contexts; Jakob Nielsen, Why you only need to test with 5 users.
Vendor and community: Figma: Guide to prototyping; Figma: Use variables in prototypes; Figma community forum: interactive text inputs in prototype mode (a user request thread, not official documentation).
Accessed 15 October 2026. Tool features change; check current documentation.
Common questions.
For a qualitative test aimed at finding problems, NN/g's long-standing guidance is about five users per round, provided they are similar to each other and you run another round after fixing what you found. Distinct audiences need their own small groups. If you need numbers you can compare, such as success rates between two designs, you need far more participants.