The Prototype Testing Guide: Validating the Solution Without Writing Code
Prototype testing is the cheapest exam for your solution hypothesis: instead of a real product, you observe the user interacting with the solution through a clickable mockup (Figma), a paper sketch, or a fake door. Interviews prove the problem exists and landing pages prove demand; the prototype answers "does our proposed solution work in the user's mind?"
Fidelity: How Realistic Should It Be?
The prototype's realism level is chosen by the question under test more polished is not always better:
| Level | Tool | What it tests |
|---|---|---|
| Paper/sketch | Drawings, whiteboard | Concept and flow logic "do these steps make sense?" |
| Low-fidelity clickable | Figma wireframes | Information architecture, task flow "does the user find the path?" |
| High-fidelity clickable | Figma final design | Comprehension, value perception, micro-decisions |
| Wizard of Oz | Real front, humans behind | The value proposition end to end delivering the service manually before automation exists |
| Fake door | A feature button that looks live | Feature demand who clicks, how much? |
The early-stage rule: low fidelity while the concept is uncertain (users focus on the idea, not the artifact, and don't hold back criticism); high fidelity when testing message and value perception. The polished prototype's trap: the user liking the design gets confused with the user endorsing the solution.
The Test Scenario: Give Tasks, Don't Give Tours
Prototype testing's most common mistake is the "product tour": you narrate, the user politely approves. The correct setup is task-based:
- Give context, not directions: "You need to build this week's shift plan with this tool. Where do you start?" not "click that menu"
- Ask for thinking aloud: "Talk through what you're thinking and expecting as you go"
- Stay silent: The urge to help when the user gets stuck erases the test's most valuable data (the sticking point). The 10-second rule: wait before rescuing
- Record behavior, not declarations: "Very useful" is worthless; "backtracked at step 3, went looking for the pricing page" is gold
- Close with the value question: "Would this replace how you do it today? Why?" hesitation here is more informative than all the compliments
Five to seven users catch most major usability issues provided they're from the same segment. Two rounds are ideal: 5 tests → fixes → 5 tests.
Wizard of Oz: End-to-End Testing Without Automation
Substituting humans for the months-long part of the software the user believes the front end is real while you do the work manually behind it is solution validation's most powerful intermediate step: instead of the "personalized weekly meal plan algorithm," a dietitian hand-builds the first 20 customers' plans. It measures more than a prototype: real usage, real repeat behavior, even real payment. The critical discipline: accept the unit cost and unsustainability upfront the goal isn't scale but the answer to "is this worth automating?"
Turning Findings into Decisions
Prototype test output sorts into three buckets: concept problems (the user doesn't understand what the solution is for → value proposition/framing revision; the heaviest signal), flow problems (understands but can't find the path → design fixes; normal and cheap), and value gaps ("I get it, but it's not better than my current way" → the solution hypothesis is weak; rethink differentiation before adding features). Bucket-one problems are not solved with design polish missing this distinction ends with two months of interface refinement applied to a concept problem.
FAQ
What's the difference between a prototype test and an MVP which comes first?
The prototype tests "is the solution understood and wanted?" via simulation; the MVP tests "is it actually used?" via real usage. The order is always prototype → MVP: discovering in the MVP a concept that would have collapsed in the prototype costs months instead of weeks. The signals for moving from prototype to MVP: users complete tasks unaided, the "can I use this today?" question arrives unprompted, and the value question gets an unhesitating yes.
Users like everything in the prototype how do I isolate the real signal?
Read behavior signals, not approval declarations: task completion time and errors, unprompted questions ("can I do this from my phone?" a genuine-interest marker), and price tests. The strongest tool is adding a micro-commitment at the end: "Shall I add you to the beta list? Would you block an hour on your calendar for a pilot? Who from your team should join?" the share saying yes is a far more honest metric than the share saying "looks great."
In a B2B product, who should test the prototype the decision maker or the end user?
Both, with different scenarios: task-based usability testing for the end user (does the daily flow work?), and a value walkthrough for the decision maker (problem-solution-outcome framing + a "would you budget for this?" close). The common mistake is running all tests with curious but unauthorized users: the product gets loved, the sale never comes. Quota them separately in your test plan: 5 end users + 3 decision makers beats 8 people from one profile.
I don't know Figma should I hire a designer for the prototype?
No need the early prototype's purpose is learning, not beauty: basic Figma with ready-made UI kits is learnable in a few days, and a first round can even run on slides with clickable links. A fake-door test needs a single screen. Designer investment makes sense after the concept is validated (at the high-fidelity + branding stage). Postponing the test because of tooling opens the road to the most expensive prototype of all: the wrong product, fully built.