← 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.

If prototype feedback is piling up and you need one documented call on what changes before build starts, use the free UI Decision Brief to capture the decision, rationale, risks, and owner.

Related Terms