Decision Tool

Prototype Fidelity Decision Matrix

A practical decision matrix and facilitation script that helps teams pick the simplest prototype fidelity (paper, mock, interactive, code, or production-like sandbox) that will produce the learning and evidence you need while minimizing cost, time, and risk.

Purpose

This decision matrix helps teams choose the lowest-fidelity prototype that will reliably answer a given learning goal. Use it to avoid overbuilding, focus on evidence, and align stakeholders on what to build, how to observe it, and when to iterate or stop.

How to use this tool

  1. Clarify the learning goal (what question you need to answer).
  2. Score the goal across a few dimensions (realism needed, interaction complexity, measurable outcomes, time sensitivity, safety/regulatory risk).
  3. Consult the matrix to see the recommended prototype type and required instrumentation.
  4. Run the smallest prototype that will produce decisive evidence; capture results against the expected evidence column.

Decision Matrix

The rows map common learning goals to prototype types, typical time & resources, recommended instrumentation, expected evidence, and an overall risk flag.

Learning Goal Recommended Prototype Types (start with simplest) Typical Time Key Resources Instrumentation (what to measure) Expected Evidence Risk Level
Value validation: will users pay/use this? Landing page, paper pitch, Wizard-of-Oz sales calls 1 day–2 weeks Copywriter, simple web page, volunteer sales reps Conversion rate, signups, pilot commitments, qualitative feedback Concrete commitments, measured interest > threshold Low
Usability: can people complete key tasks? Paper prototypes, clickable mockups, moderated usability tests 1–7 days Prototyper, facilitator, 5–10 users Task success, time on task, errors, verbal cues Usability metrics and observed failure modes Low–Medium
Feasibility/Performance: can the system meet technical constraints? Functional prototype (partial code), sandboxed performance tests 1–8 weeks Engineers, test environment, test data Latency, throughput, stability, resource usage Measured performance vs required thresholds Medium–High
Integration/Operations: will this work in real workflows? End-to-end wire-up in test environment, configurable mocks 2–12 weeks Devops, APIs, operations staff, test users Error rates, handoff failures, support load Operational readiness signals, runbook validation High
Pricing & business model Fake door tests, pricing experiments, pre-orders 1–6 weeks Marketing, simple checkout, analytics Conversion at price points, willingness-to-pay surveys Demand elasticity, revenue projections from pilots Low–Medium
Regulatory or safety concerns Production-like sandbox, controlled pilots with approvals 4+ weeks (may require formal approvals) Compliance, legal, safety officers, test protocols Adverse event logs, compliance checklists, audit trails Regulatory sign-off criteria, safety incident rates High

Quick scoring rubric (facilitation)

For the learning goal, score 1–5 on each dimension:

  • Realism required (1 = conceptual OK, 5 = production-like realism required)
  • Interaction complexity (1 = single click/choice, 5 = complex multi-step flows)
  • Measurability (1 = qualitative OK, 5 = precise quantitative metrics required)
  • Time sensitivity (1 = slow feedback OK, 5 = fast decision required)
  • Safety/regulatory risk (1 = none, 5 = critical)

Decision heuristics:

  • If any Safety score = 4–5 → consider production-like sandbox and involve compliance before testing.
  • If Realism + Interaction + Measurability ≤ 6 → start with paper or clickable mock.
  • If Measurability ≥ 4 and Performance matters → choose a functional prototype with instrumentation.
  • Prefer Wizard-of-Oz for value tests when building the backend is costly but human mimicry will reveal truth.

Facilitation prompts

  1. What exact decision will this prototype help us make? (e.g., "Should we build billing automation?")
  2. What would we accept as decisive evidence? (numbers, observed behavior, committed dollars)
  3. What is the minimum realism we need to produce that evidence?
  4. Who must be involved to observe or authorize this test?
  5. How will we label, timebox, and retire the prototype?

Sample decision scenarios

Scenario A — New checkout flow: Goal = reduce abandonment. Score: Realism 4, Interaction 4, Measurability 5, Risk 2 → Recommended: Clickable mock + Wizard-of-Oz checkout or limited functional prototype instrumented to measure conversion. Timebox: 2 weeks.

Scenario B — New sensor-driven feature on production line: Goal = assess detection accuracy and latency. Score: Realism 5, Interaction 2, Measurability 5, Risk 4 → Recommended: Functional prototype in sandbox with real sensor data; safety review required.

Prototype checklist (pre-launch)

  • Define success criteria and numeric thresholds.
  • Label prototype clearly ("Prototype — not for production").
  • Assign observer(s) and data capture responsibilities.
  • Plan participant recruitment and consent (if applicable).
  • Timebox the experiment and define retirement or hardening criteria.

Next steps after the prototype

  1. Compare observed evidence to success criteria; document learnings.
  2. Decide: Iterate, pivot, scale, harden to production, or retire.
  3. Capture decisions and artifacts in your team knowledge base so future teams reuse the learning.

Image search phrase: prototype fidelity matrix

Discuss Ask the Librarian

Discussion

Comments and conversation will live here.