A prototype is an early model of a product built to test ideas before committing to build them.
Notice the two halves of that definition. A prototype is a model, which means it only needs to be real enough to stand in for the product. And it exists to test ideas, which means it earns its keep by teaching you something, not by looking impressive.
A prototype can be almost anything: a stack of paper sketches you swap by hand, a set of clickable screens, or a coded interaction that feels close to the finished thing. What makes it a prototype is not the material. A prototype is defined by its purpose: it lets you experience an idea and react to it before the idea gets expensive.
By the time you reach prototyping, you already have wireframes, flows, and a clear problem to solve. The prototype is where those static artifacts start to move. Buttons respond, screens connect, and for the first time someone can actually try your design instead of just looking at it.
Here's the discipline that separates useful prototyping from busywork: every prototype should exist to answer a specific question. If you can't say what question a prototype is testing, you're not prototyping. You're decorating.
Good prototype questions are concrete. Can a first-time user of our booking app find the date picker without help? Does splitting checkout into three steps feel faster or slower than one long form? Will people understand that swiping left archives a message?
The question determines everything else: what you build, how polished it needs to be, and how much of the product you include. If the question is about navigation, you don't need real content or final colors. If the question is about whether an animation communicates state, you might need exactly one screen, built carefully.
Write the question down before you open a design tool. It keeps you honest when the prototype starts growing in directions that feel fun but answer nothing.
Fidelity is how closely a prototype resembles the final product, in visuals, content, and interactivity.
Fidelity is a spectrum, from paper sketches at one end to a near-real experience at the other. Neither end is better. The right fidelity is the cheapest one that can still answer your question.
Paper sketches, whiteboard flows, and rough digital frames stitched together with basic links. Low fidelity earns its keep early, when the big questions are still open: Is this flow in the right order? Are we missing a step? Does the core concept make sense at all?
Because a low-fidelity prototype looks unfinished, people treat it as unfinished. They critique the idea instead of the font, and they aren't shy about telling you a whole screen should go. That bluntness is exactly what you need at this stage.
Clickable wireframes with real structure, plausible content, and working navigation, but without final visual polish. Mid fidelity is where you test whether people can actually complete tasks: find a product, compare two plans, finish a signup.
This is often the workhorse of a project. It's cheap enough to change after every round of feedback, but real enough that users forget they're clicking through a mockup.
Near-real screens with final visuals, real copy, and detailed interactions. High fidelity earns its keep late, when the questions get fine-grained: Does this contrast hold up on a phone in daylight? Does the transition make the hierarchy clear? Does the empty state feel reassuring or alarming?
High fidelity is expensive to build and expensive to change, so save it for questions that genuinely require realism. Testing a flow's basic logic in high fidelity is like renting a truck to deliver a letter.
Not every prototype is for users. Sometimes you build one to convince a stakeholder that an idea deserves budget, or to help engineers feel what a spec can't describe. That's legitimate work, but be clear-eyed about it: a prototype built to persuade is a different artifact from a prototype built to learn, and mixing the two goals ruins both.
A learning prototype is deliberately rough where roughness doesn't matter, and it's built to be torn apart. A persuasion prototype is polished, rehearsed, and built to survive a demo without breaking. If you drag your fragile learning prototype into a boardroom, it stumbles and the idea gets blamed. If you put your polished demo in front of users, its shine intimidates them into politeness, and you learn nothing.
Decide which one you're making before you start, and label it honestly for your team. It's fine to build both. It's not fine to pretend one is the other.
The most common prototyping mistake isn't building too little. It's building too much. Design tools make it seductively easy to keep adding screens and polishing micro-interactions nobody asked about.
A beautiful prototype nobody tested is decoration, not design work.
Over-building costs you three times. First, the hours themselves. Second, the flexibility: the more you've invested in a prototype, the more painful it is to change, so feedback starts feeling like an attack instead of a gift. Third, and worst, your own judgment. The more polished a prototype becomes, the harder it is for anyone, including you, to question the idea underneath it.
A useful habit: before adding anything to a prototype, ask whether it helps answer the question you wrote down. If it doesn't, it's scope creep wearing a nice coat.
Prototyping can become a comfortable place to hide. Each new round feels productive, and a prototype never has to face real data or real support tickets.
You've prototyped enough when your open questions can no longer be answered by a model. If the remaining unknowns are about how people behave over weeks, with their own data, in their own messy context, no prototype will tell you. Only the real product will.
Stop prototyping when the next thing you'd learn from a prototype is smaller than what you'd learn from shipping. That doesn't mean ship everything; it means ship the slice you've validated, watch what happens, and bring the new questions back into the next round of design.
A prototype is a question made tangible: build the cheapest model that can answer it, then move on.
Know what you're testing before you build. Match fidelity to the question, not to your ambitions. Keep learning prototypes and persuasion prototypes separate. And when a prototype has taught you all it can, let it go and ship.