← Go Back

Prototyping

What is prototyping?

Prototyping is the process of creating interactive models of a product or flow so you can test ideas, validate user flows, and get feedback before building. Outputs range from clickable wireframes to high-fidelity simulations. See Prototype for the artefact.

Use it when: you have a flow or concept you want to validate with users or stakeholders before committing to code. Prototyping answers “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 for structure and flow; high for visual and copy feedback.
  • [ ] Scope – Only the screens or steps needed to test that question.
  • [ ] Who will use it – Users for usability testing; stakeholders for alignment.

Why prototyping matters

  • Reduces risk by testing before you code.
  • Makes ideas concrete so teams and users can react to something real.
  • Surfaces problems when they’re cheap to fix.
  • Speeds alignment and decision-making.

What good prototyping includes

Checklist

  • [ ] Focused – Built to answer one or two questions, not to show everything.
  • [ ] Interactive enough – Users can complete the flow you’re testing.
  • [ ] Appropriate fidelity – Low when testing structure; higher when testing look, feel, or copy.
  • [ ] Documented – What you tested, what you learned, what you’ll change.
  • [ ] Iterative – Build, test, learn, refine. See iterative design.

Common formats

  • Low-fidelity: Clickable wireframes or sketches. Use for structure, navigation, and flow.
  • High-fidelity: Looks and behaves like the product. Use for visual feedback, copy, and final usability testing.
  • Paper: Quick and cheap for early ideation; not for remote testing.

Examples

Example (the realistic one)

You want to test whether users can find “upgrade” and understand pricing. You build a clickable prototype in Figma: homepage, pricing page, one “after upgrade” screen. No real payment. You run 5 usability tests; 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; feedback is scattered. → Do this instead: define what you’re testing and build only what’s needed.
  • High fidelity too early: feedback focuses on colour and copy when you needed flow. → Do this instead: start low-fi; increase fidelity when the question demands it.
  • No user testing: prototype is only for internal review. → Do this instead: put it in front of users; see usability testing.
  • Confusing with MVP: a prototype simulates; an MVP is a real product. → Do this instead: use prototyping to learn; use MVP when you’re ready to ship and learn from live use.
  • Prototyping vs wireframing: wireframing produces static structure; prototyping adds interaction. Wireframes often feed into prototypes.
  • Prototyping vs MVP: MVP is a minimal but real product; a prototype is for testing and learning. When you’re ready to learn from real use, build an MVP.
  • Prototyping vs mockup: a mockup is usually static; a prototype is interactive. Prototypes show how it works; mockups show how it looks.

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. Read Prototype for the full checklist.

Related Terms