The cheapest way to find out you were wrong — before you've built anything.

A prototype is a simulation of a product or feature — something interactive enough to test, but not fully built. Its purpose is to answer a specific question before committing development resources.

The key phrase is "answer a question." A prototype without a question is just an expensive demo. The best ones are built to test a single assumption — will users understand how to navigate this flow? Does this control make sense without explanation? — and nothing else. Scope creep in prototypes is real and eats the time savings the approach is supposed to provide.

Prototypes range from paper sketches to near-production builds:

• Paper prototypes: Physical printouts or hand-drawn screens used to test basic flows. Fast to make, easy to modify, useful for early-stage navigation testing before any digital work is done.
• Click-through prototypes: Built in tools like Figma or Framer. Good for testing flow and interaction patterns without writing code. The most common type for UX work.
• Coded prototypes: Built in real code, closer to production. Necessary when the interaction or performance characteristics are central to what's being tested — animations, latency, real data.

Fidelity should match the question. Testing whether a flow makes sense doesn't require a coded prototype. Testing whether a real-time update feels fast enough does.

Prototypes surface problems that static mockups hide. A layout that looks clean in a design file can feel disorienting when you're actually clicking through it. Copy that seems clear on a screen becomes ambiguous the moment a user has to decide what to do based on it.

They also expose assumptions the team didn't realize they were making. When a user does something unexpected in a test session — takes a completely different path, looks for a control that doesn't exist — that moment of surprise is usually worth more than hours of design review. Pair prototyping with Usability Testing to capture those moments systematically.

Not every feature needs a prototype. For simple changes — adding a field to an existing form, updating a label, adjusting a component state — prototyping adds overhead without adding insight.

Prototyping is also the wrong tool when the core uncertainty is technical rather than experiential. If the question is "can we make this fast enough?" a performance spike may help. If the question is "will users understand this interaction?" a click-through prototype will. Knowing which question you're asking determines which kind of build is worth making.

These two terms get used interchangeably but they test different things. A prototype tests the user experience — how does this feel, can users understand it, does the flow make sense? A proof of concept tests technical feasibility — can we build this at all, does the approach hold up at scale?

Product teams that conflate them often build proofs of concept when they should be testing user behavior, and vice versa. They're complementary, not interchangeable. A Design Sprint is designed around prototyping specifically — it reaches a testable simulation by Thursday so Friday's user sessions have something to react to.