What is Prototype Testing?

Prototype testing is the evaluation of a prototype, a simulation of a product that looks or behaves like the real thing to some degree, by observing target users attempting realistic tasks with it and gathering their reactions. It is usability testing applied before the product exists, and it can be run on anything from hand-drawn screens to an interactive mockup that is indistinguishable from the shipped app. The method's economics are the whole argument for it: a confusing flow discovered on a Figma prototype is a design change; the same flow discovered after launch is engineering time, support tickets, and lost users. Modern tooling made it routine: a clickable prototype can be uploaded to a research platform, sent to screened participants, and watched as recorded sessions the same day (the core loop of a Ballpark prototype study).

Fidelity Decides What You Learn

Low fidelity (sketches, wireframes, gray boxes) tests structure, flow, concept, and terminology. Participants forgive the roughness and comment on substance; they also can't judge visual polish or interaction detail, because there isn't any. Best for early, formative questions: is the flow right, do the labels make sense, does the concept land?

Mid fidelity (clickable wireframes with real copy and basic interaction) tests navigation, task completion, and content comprehension. The workhorse of iterative design rounds.

High fidelity (near-final visuals and interaction) tests visual hierarchy, micro-interactions, perceived quality, and the details that only appear when the design looks real. Participants also become more polite about a design that looks finished, and teams become more attached to it, which is why high fidelity comes last.

The rule: test at the lowest fidelity that can answer the question, and increase fidelity only as questions get more specific. The related fidelity trade-offs are covered under prototype fidelity.

Running It Well

1. Write real tasks.
Goal-based task scenarios in the participant's language, with no interface labels leaking in. The prototype test is only as good as its tasks.

2. Build only the paths the tasks need.
A prototype doesn't have to be complete; it has to support the tasks. Dead ends off the tested path are fine if the tasks don't lead there; dead ends on the path derail the session.

3. Tell participants it's a prototype.
"Some parts won't work; say what you'd expect to happen" turns a broken link into data about expectations instead of a confused silence.

4. Capture behavior and reaction together.
Task success, paths, and time from the recording; expectations and confusion from think-aloud narration or a recorded answer after each task. The behavior says what happened, the reaction says why.

5. Test in rounds.
Five participants, fix, five more. Iteration finds more than a single large round because fixes reveal the problems they were hiding.

6. Choose moderated or unmoderated by the question.
Unmoderated for clean, scalable evaluation of a flow that works; moderated for rough prototypes and open questions where a human needs to bridge the gaps.

The Common Failures

Testing too late, when the prototype is finished and nobody wants to hear about it. Testing with colleagues instead of the target audience. Asking "do you like it?" instead of watching whether it works (the preference question is a different method). Building an elaborate prototype for a question a sketch could answer. And reporting "users loved it" from a session where users failed the second task politely.

The Bottom Line

Prototype testing puts the product in users' hands before it exists, at the fidelity the question needs, with real tasks and real participants, in rounds that fix and re-test. It is where usability problems are cheapest to find and cheapest to fix. Test early, test rough, test the audience, watch behavior before opinion, and treat every round's findings as changes rather than verdicts.