Iteration Prototype Fidelity

Picking the right prototype fidelity

Each prototype fidelity is a tool with a cost and a use. Sketches are nearly free but answer only structural questions. Code prototypes cost more but answer performance and behavior questions. The discipline is matching fidelity to the question being asked — not always going lowest, not always going highest.

The fidelity ladder

From cheapest to most expensive:

1. Paper sketches

A pen and paper. Cost: 5–30 minutes per option. Answers:

• Does this layout structure make sense?
• Are the right elements present?
• What's the rough information architecture?

Doesn't answer:

• How does it feel to interact with this?
• Does the typography work?
• Are colors right?

When to stop here: structural questions only; very early discovery.

2. Wireframes (low-fidelity digital)

Boxy, monochrome, no real content. Cost: 1–4 hours per screen. Answers:

• Layout proportions on screen.
• Reading order and hierarchy.
• Information grouping.

Doesn't answer:

• Visual style.
• Interaction feel.
• Real-content edge cases.

When to stop here: when structure is the question; before visual design begins.

3. Mockups (high-fidelity static)

Real fonts, colors, content; static image. Cost: 4–16 hours per screen. Answers:

• Visual style.
• Polish and brand fit.
• Stakeholder alignment ("does this look right?").

Doesn't answer:

• Interaction.
• Edge cases.
• Performance.

Common misuse: building high-fidelity mockups before structure is settled. The mockups become anchors that prevent structural changes.

4. Clickable prototypes (Figma, Framer, ProtoPie)

Mockups linked together with click-throughs. Cost: 1–3 days per major flow. Answers:

• Does the interaction sequence make sense?
• Where do users get confused?
• Are the affordances clear?

Doesn't answer:

• Real-content edge cases.
• Performance.
• Cross-device behavior.

Sweet spot for most user research; cheap enough to revise, real enough to test.

5. Code prototypes

Working code with real or seeded data, but not production-ready. Cost: 1–3 weeks. Answers:

• Performance.
• Cross-device behavior.
• Real-data edge cases.
• Implementation complexity.

Doesn't answer:

• Long-term scale issues.
• Production reliability.

Useful when implementation has unknowns or when performance is a concern.

6. Production beta

Shipped to a small percentage of real users. Cost: high (full implementation). Answers:

• Real usage at scale.
• Bug rates.
• Long-term retention.
• Real edge cases.

Doesn't answer (well):

• Counterfactual: would users have liked the alternative more?

When to use: late-stage validation; gradual rollout.

Picking the right fidelity for each question

A useful rule: pick the cheapest fidelity that answers the question.

Going higher than needed wastes time. Going lower means you don't get the answer.

When to stay low fidelity longer

Counterintuitively, low fidelity is often better for user research:

• Users critique the prototype's polish, not its structure. A high-fidelity mockup gets feedback like "I don't love this blue" instead of "I don't understand what this page is for." The polish distracts.
• Low fidelity invites criticism. Users feel comfortable suggesting changes to a sketch; they hesitate to challenge a polished mockup.
• Low fidelity is faster to revise. You can make 5 sketch variations in the time it takes to make 1 mockup variation.

For early-stage user research, sketches and wireframes often outperform high-fidelity prototypes despite "feeling unprofessional."

When to go high fidelity earlier

A few cases where polish matters:

• Stakeholder buy-in. Some stakeholders only react meaningfully to high-fidelity mockups. Build them for those reviews.
• Brand-perception research. Testing whether a design feels like the brand requires polish.
• Competitive comparison. Comparing your design's appeal to a competitor's polished product needs comparable polish.

Anti-patterns

• Pixel-perfect early. Polishing visual details before structure is settled. The pixels then have to be redone.
• Test with the prototype that was easy to build. Using a Figma prototype to test load-time performance, or a code prototype to test layout structure. Wrong fidelity for the question.
• Skip prototyping entirely. "We're agile, we'll just build it." Then iterate expensively in production.
• Production-quality prototypes. Building prototypes to production code quality. Defeats the cost advantage of prototyping.
• Treating prototypes as products. Shipping a prototype as the product because it "works." Usually missing edge cases, accessibility, performance.

Worked example: layered prototyping for a new feature

A team designs a new collaboration feature.

• Week 1: paper sketches; internal review. Decide structural concept.
• Week 2: wireframes; design crit. Refine information architecture.
• Week 3: clickable Figma prototype; 5 user interviews. Discover one critical flow is confusing; redesign.
• Week 4: refined Figma prototype; 5 more interviews. Confirm the redesign works.
• Week 5–6: code prototype with real data. Surface a performance issue; design adapts.
• Week 7–10: production build. Ship to 10% beta.
• Week 11–12: full release.

Each cycle uses the cheapest fidelity that answers the cycle's question.

Heuristics

1. The "what question is this prototype answering?" check. Before building the prototype, name the question. Pick the fidelity that answers it.
2. The "could a sketch have caught this?" retrospective. When issues are discovered late, ask whether earlier prototyping at lower fidelity would have caught them.
3. The user-reaction signal. If users critique your prototype's visual polish, you're at too high fidelity for the question. Drop down.

Related sub-skills

• iteration (parent).
• iteration-design-vs-development — moving up the fidelity ladder is part of moving from design to development.
• prototyping — the broader technique.
• factor-of-safety — prototypes are a form of designing-with-margin.