Prototype Fidelity Check¶
Test or assessment — instantiates Layered Model Validation
Checks whether making a prototype more realistic actually improves the learning, usability judgment, or readiness it was meant to inform — rather than just adding polish.
Prototype Fidelity Check treats added realism as a layer that must earn its cost. A prototype gets more faithful — real visuals instead of wireframes, live data instead of stubs, working flows instead of clickable stills — and the question is not "does it look more finished?" but "does the added fidelity improve the judgment we draw from it?" Its defining move is to tie the fidelity increase to a specific decision the prototype is meant to inform — will users understand the workflow, is the concept worth building, are stakeholders ready to commit — and to check whether the more realistic version actually sharpens that decision on representative tasks. Unlike the other tests in this family, its outcome is not a number matched against reality but a judgment about a design, which is exactly why its central risk is mistaking polish for validity.
Example¶
A medical-device team is designing the touchscreen a nurse uses to program an infusion pump. Their low-fidelity prototype — gray boxes, tap-through screens — already surfaced the basic flow. Someone proposes a high-fidelity build: real typography, animated confirmations, production color. Before funding it, they run a fidelity check. They state what the extra realism is supposed to buy: clearer detection of dose-entry errors during realistic, time-pressured tasks. They pick a handful of sentinel scenarios — the exact error-prone moments the device exists to make safe, such as entering a decimal dose under interruption — and run nurses through both prototypes on those tasks.
The check earns its keep by separating two outcomes. If the high-fidelity version genuinely helps nurses catch mis-keyed doses that the gray-box version hid behind ambiguity, the realism improved the safety judgment and is worth building. If instead nurses simply rate the polished version as "nicer" while catching errors at the same rate, the fidelity added appeal but not decision value — and the team marks the boundary: this prototype validates the interaction, not the clinical dosing logic, which needs its own study.
How it works¶
The check is defined by making realism accountable to a decision:
- Name the judgment the fidelity should improve. Learning, usability, error-detection, buildability, or stakeholder readiness — pick the one the increase is for.
- Test on representative tasks, not a demo. Put both fidelity levels in front of real users doing the critical tasks, so the comparison is about behavior and not first impressions.
- Separate reaction from performance. Track what users do (errors, completion, comprehension), not only what they say, because appeal and understanding diverge.
- Fence the conclusion. State what the prototype's fidelity does and does not license a decision about, so a realistic look is not read as validation of things it never tested.
Tuning parameters¶
- Fidelity dimension — visual, data, interaction, or scope realism. Each answers a different question; raising the wrong one adds cost without informing the decision.
- Target judgment — the specific decision the check serves. A vaguely-aimed check invites "it looks better" as a passing verdict.
- Task realism — how closely test tasks mirror real conditions (interruptions, stakes, time pressure). Sanitized tasks flatter both prototypes equally and reveal little.
- Behavior vs. preference weighting — how much observed performance counts against stated liking. Leaning on preference is where realism theater slips in.
- Fidelity ceiling — how far to push realism before returns vanish. Past the point the decision needs, extra polish is sunk effort.
When it helps, and when it misleads¶
Its strength is that it stops teams from confusing a finished-looking artifact with a validated design, and it locates fidelity spend where it changes a decision — often revealing that a rough prototype was already enough. It keeps "make it more realistic" honest by demanding the realism pay for itself in better judgment.
Its signature failure is the aesthetic-usability effect: users perceive more attractive interfaces as more usable[1], so a high-fidelity prototype can score better on satisfaction while its actual usability is no different, quietly rewarding polish over substance. A related trap is premature commitment — a realistic prototype makes a design feel decided, chilling the criticism a rougher version would have invited. And fidelity is domain-local: a prototype realistic in look can be entirely unvalidated in logic or performance. The discipline is to judge on observed behavior over stated preference, run the critical tasks rather than a happy-path demo, and explicitly bound what the fidelity level has and has not validated.
How it implements the components¶
Prototype Fidelity Check fills the is-the-added-realism-worth-it slice of the archetype:
expected_value_of_added_layer— it requires the fidelity increase to name what judgment it should improve before the build, so realism is measured against a claim rather than assumed valuable.sentinel_scenario— the critical, error-prone tasks the prototype is run through are the representative cases where the added realism must prove it matters.validity_boundary— it marks what the fidelity level legitimately validates (say, the interaction) and what it does not (the underlying logic), preventing a polished look from being over-read.
It does not measure a layer's effect by removing it (ablation_or_isolation_plan) — that is Ablation Test; nor score outputs against a recorded factual baseline (comparison_baseline) — that is Backtesting Against Known Cases. This check evaluates whether added realism improves a design judgment, not numerical correspondence to data.
Related¶
- Instantiates: Layered Model Validation — supplies the verdict on whether a fidelity increase improves the decision the prototype informs.
- Sibling mechanisms: Ablation Test · Backtesting Against Known Cases · Regression Test for Added Complexity · Incremental Design Review · Model Validation Ladder · Policy Pilot Validation · Staged Simulation Validation · Sensitivity Analysis
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Prototype Fidelity Check operates by puts representative users through critical tasks at two fidelity levels to generate comparative evidence. That concrete deployed or enacted form is Experiment, Test & Rehearsal under the frozen taxonomy.
Nearest alternative: Assessment, Review & Assurance — Although Assessment, Review & Assurance can support this mechanism, the frozen evidence makes its operative form the act that puts representative users through critical tasks at two fidelity levels to generate comparative evidence; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Human-Computer Interaction
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Matching a prototype's manifested resolution and scope to the quality being investigated is a canonical HCI prototyping concern; the cited TOCHI work explicitly relates prototype manifestation to the design question and resulting interpretation.
Related originating lineages:
- Engineering & Design — Engineering prototyping independently developed staged fidelity and validation against design risk.
Review resolution: The blind reviewers disagreed on primary lineage. Light authoritative research resolves the defining form in favor of human_computer_interaction: Matching a prototype's manifested resolution and scope to the quality being investigated is a canonical HCI prototyping concern; the cited TOCHI work explicitly relates prototype manifestation to the design question and resulting interpretation. The other materially formative traditions are retained as alternates; current breadth of use remains separate as domain_reach=multi_domain.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
References¶
[1] Kurosu, M., & Kashimura, K. "Apparent Usability vs. Inherent Usability: Experimental Analysis on the Determinants of the Apparent Usability". CHI '95: Conference Companion on Human Factors in Computing Systems, 292–293 (1995). Finds that interface aesthetics strongly influence apparent-usability judgments, which are only weakly related to inherent usability. registry ↩