← Go Back

Prototype

What is a prototype?

A prototype is a working model of a product or feature that you can use to test ideas and get feedback before building the real thing. It can be rough (paper, clickable wireframes) or close to final (high-fidelity); the point is to learn and iterate cheaply.

Use it when: you have an idea or flow you want to validate with users or stakeholders before committing to build. Prototypes answer “will this work?” and “where does it break?”.

Copy/paste checklist (before you prototype)

  • [ ] What we’re testing: One question or assumption (e.g. “Do users understand this flow?”).
  • [ ] Fidelity: Low (sketch/boxes) for structure and flow; high (looks real) for visual and copy feedback.
  • [ ] Scope: Only the screens/steps needed to test that question.
  • [ ] Who will use it: Users for usability; stakeholders for alignment. Don’t overbuild for the wrong audience.

Why prototypes matter

  • Reduce risk by testing before you code.
  • Make ideas concrete so teams and users can react to something real.
  • Speed up alignment and decision-making.
  • Surface problems when they’re cheap to fix.

What a good prototype includes

Checklist

  • [ ] Focused – built to answer one or two questions, not to show everything.
  • [ ] Interactive enough – users can complete the flow you’re testing (even if it’s just key clicks).
  • [ ] Appropriate fidelity – low when testing structure and flow; higher when testing look, feel, or copy.
  • [ ] Documented – what you tested, what you learned, what you’ll change.

Common formats

  • Low-fidelity: sketches, wireframes, simple click-throughs. Use for structure, navigation, and flow.
  • High-fidelity: looks and behaves like the product. Use for visual feedback, copy, and final usability checks.
  • Paper: quick and cheap; good for early ideation and co-design. Not for remote testing.

Examples

Example (the realistic one)

You want to test whether users can find “upgrade” and understand the pricing tiers. You build a clickable prototype in Figma: homepage, pricing page, and one “after upgrade” screen. No real payment. You run 5 usability sessions; the prototype is enough to see where people get lost. You iterate on the prototype, then hand the validated flow to development.

Common pitfalls

  • Prototyping everything: no clear question, so feedback is scattered. → Do this instead: define what you’re testing and build only what’s needed for that.
  • High fidelity too early: you get feedback on colour and copy when you needed flow feedback. → Do this instead: start low-fi; increase fidelity when the question demands it.
  • Treating it as the spec: prototypes are for learning, not necessarily the final design. → Do this instead: use prototype learnings to inform the real build; don’t assume every detail is final.
  • Confusing prototype with MVP: a prototype simulates; an MVP is a real product people use. → Do this instead: use MVP when you’re ready to ship and learn from live use.
  • Prototype vs wireframe: a wireframe is a static layout (often low-fidelity); a prototype is interactive. Wireframes can be the basis of a prototype.
  • Prototype vs MVP: a prototype is for testing and learning; an MVP is a minimal but real product in users’ hands. When you’re ready to learn from real use and data, build an MVP.
  • Prototype vs mockup: a mockup is usually a static visual; a prototype has interaction (clicks, flows). Mockups show “what it looks like”; prototypes show “how it works”.

Next step

Choose one flow you’re unsure about, build a low-fidelity clickable prototype (even 3–5 screens), and run usability testing with 5 users. Summarise what you learned and what you’ll change.

Related Terms