thedixitjain 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.
| Question | Recommended fidelity |
|---|---|
| Does the IA make sense? | Sketches or wireframes |
| Is the visual style right? | High-fidelity mockup |
| Does the flow work for users? | Clickable prototype + 5 interviews |
| Will the load time be acceptable? | Code prototype with seeded data |
| Will users adopt it? | Production beta with measurement |
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
- The "what question is this prototype answering?" check. Before building the prototype, name the question. Pick the fidelity that answers it.
- The "could a sketch have caught this?" retrospective. When issues are discovered late, ask whether earlier prototyping at lower fidelity would have caught them.
- 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.
Source: hashgraph-online/awesome-codex-plugins → plugins/HDeibler/universal-design-principles/plugins/process-and-robustness-principles/skills/iteration-prototype-fidelity/SKILL.md