Prototype Fidelity Matrix

A practical guide to choosing the lowest-cost, fastest prototype that reliably tests your riskiest assumptions. Includes mapping from learning goals to prototype types, cost/time/risk heuristics, recommended tooling and team roles, example evaluation rubrics, and a ready-to-use engineering handoff checklist.

Prototype Fidelity Matrix

Choose the cheapest, fastest prototype that will reliably answer the question you care about. This matrix helps you match learning goals to prototype fidelity (paper, click-through, service mock, minimal backend, concierge, smoke test) and gives practical advice on cost, time, risk, tooling, roles, evaluation, and handoffs.

Why fidelity matters

Prototype fidelity is not about polish — it’s about precision. The right fidelity focuses your team on the specific assumption you need to test and avoids wasting time building features you haven’t validated. Use lower fidelity for broad, qualitative learning and higher fidelity only when you need accurate performance, integration, or compliance data.

Learning goals & recommended fidelity

  • Desirability (do customers want this?) — Paper prototypes, sketches, clickable mocks, concierge prototypes. Cost: low. Time: hours–days. Risk: low.
  • Usability (can people use it?) — Clickable prototypes, moderated usability sessions, service walkthroughs. Cost: low–medium. Time: days–2 weeks. Risk: low.
  • Feasibility (can we build it?) — Spike prototypes, minimal backend integrations, technical spikes. Cost: medium. Time: days–weeks. Risk: medium.
  • Performance & scale (will it perform in production?) — Production-like bench tests, limited soft launches, load testing. Cost: high. Time: weeks–months. Risk: high.
  • Business viability (will it generate revenue/meet ops constraints?) — Concierge/service mocks, smoke tests, pilot programs, landing pages with conversions. Cost: low–medium. Time: days–weeks. Risk: medium.
  • Compliance & safety (regulatory or safety constraints) — Controlled lab tests, compliance-focused prototypes, hardened prototypes with oversight. Cost: medium–high. Time: weeks–months. Risk: high (do not shortcut).

Common fidelity options (quick reference)

  • Sketch / Paper — Fast concept exploration, workflows, and early alignment. Best for: desirability and early UX ideas.
  • Clickable (no backend) — Simulated UI flows to test navigation and basic usability. Best for: usability and early desirability testing.
  • Concierge / Manual Service — Humans deliver the experience behind the scenes. Best for: validating value before automation (viability & desirability).
  • Wizard of Oz — Interfaces appear automated while hidden human processes run the logic. Best for: complex interactions and edge-case behavior learning.
  • Minimal Backend / Spike — Small production-like components to validate integration and feasibility assumptions.
  • Soft Launch / Smoke Test — Limited production release to measure real-world behavior and core metrics.
  • Production-like Pilot — Near-production implementation to validate compliance, performance, scaling, and operations.

Cost / time / risk heuristics

Low fidelity

  • Examples: paper, sketches, clickable mocks (Figma), role-play
  • Cost: low; Time: hours–days; Risk: low
  • Use when you want rapid feedback on desirability, concept fit, or high-level flows.

Medium fidelity

  • Examples: clickable prototypes with simple interactions, concierge services, Wizard of Oz
  • Cost: low–medium; Time: days–weeks; Risk: medium
  • Use to validate usability, initial conversion signals, or small technical integrations.

High fidelity

  • Examples: minimal backend, production smoke tests, pilot deployments
  • Cost: medium–high; Time: weeks–months; Risk: high
  • Use when you must validate scalability, compliance, performance, or full economics.

Recommended tooling & team roles by fidelity

  • Sketch / Paper — Tools: pen, whiteboard, miro, sketching kit. Team: designer, product lead, facilitator, 2–4 stakeholders.
  • Clickable prototype — Tools: Figma, Adobe XD, InVision. Team: designer, UX researcher, product manager, optional engineer reviewer.
  • Concierge / Wizard of Oz — Tools: simple forms, spreadsheets, scheduling tools, and scripts. Team: product lead, ops/human operators, researcher, customer-facing staff.
  • Minimal backend / spike — Tools: small code repo, mock APIs, lightweight infra (serverless). Team: 1–2 engineers, architect, product manager, QA as needed.
  • Soft launch / pilot — Tools: feature flags, monitoring, analytics, lightweight infra, support workflows. Team: engineers, SRE or ops, product, support, compliance/QA.

Evaluation rubrics: what to measure and how

Define success criteria before you build. A simple rubric helps teams decide whether to iterate, scale, pivot, or stop.

  1. Learning question — State the explicit hypothesis. Example: “Concierge users will complete task X within 3 steps and be willing to pay $Y.”
  2. Primary signal — The most direct metric or observation that answers the question (qual or quant). Example: conversion rate, task completion rate, NPS, qualitative interview themes.
  3. Thresholds — Define pass / pivot / fail ranges. Example: >30% conversion = scale; 10–30% = iterate; <10% = pivot.
  4. Secondary signals — Supporting metrics such as time to complete, support requests, error types, retention.
  5. Contextual notes — Who participated, environment, recruitment method, known biases (lab, paid testers, organic users).

Quick decision checklist

  • What assumption is riskiest? (desirability / usability / feasibility / performance / compliance)
  • Do I need realistic performance data or only behavioral signals?
  • Can humans simulate the solution reliably for a short period?
  • Is regulatory or safety compliance required for testing? If yes, escalate for governance.
  • What success thresholds will allow us to act?

Example engineering handoff checklist (quick template)

  • Prototype ID & goal: Short name and the hypothesis being tested.
  • Target users / cohort: Who will participate and why.
  • Required fidelity elements: UI screens, mocked APIs, data flows, edge-cases to simulate.
  • Data capture: Events to log, analytics keys, and experiment flags.
  • Success metrics & thresholds: Primary/secondary signals and action thresholds.
  • Operational plan: Who will operate, fallbacks, support contacts, and how to stop the experiment.
  • Compliance notes: Any legal, security, or privacy requirements.
  • Retirement or hardening plan: How to retire the prototype or convert parts to production if validated.

Common mistakes to avoid

  • Building a production-ready system instead of a focused experiment.
  • Measuring vanity metrics that don’t answer the hypothesis.
  • Recruiting biased testers (friends, internal stakeholders) without noting biases.
  • Skipping compliance reviews for regulated domains.
  • Not pre-defining stop / scale criteria.

Next steps and variations

Use this guide during your next discovery sprint. Start with the riskiest assumption, choose the lowest-fidelity option that can answer it, define your rubric, and run short, time-boxed experiments. When you notice patterns, consolidate learning, and only then consider moving to higher fidelity.

Template downloads and reusable toolkit suggestion: Consider packaging this matrix with editable rubrics, Figma prototype starter files, a concierge script, and the engineering handoff checklist as a reusable Toolkit for teams to copy and adapt.


Discussion

Comments and conversation will live here.