Prototype Test¶
Test or assessment — instantiates Bounded Approximation
Uses a partial or low-fidelity implementation as an approximation of later system behavior.
A Prototype Test builds a partial or low-fidelity version of the eventual system and observes its behaviour as an approximation of how the full system will behave — with every reading filtered through the prototype's fidelity gap: which aspects it faithfully represents and which it fakes, stubs, or leaves out entirely. Its defining move is that discipline of interpretation. A prototype is faithful on some dimensions (how it looks, how a part fits the hand) and silent or false on others (how it performs, how it lasts), and the mechanism's value collapses the moment a result is read beyond what the prototype can actually speak to. Unlike a policy pilot, which is the real intervention deployed to a small real population, a prototype is an engineering artifact whose approximation lies in fidelity, not coverage.
Example¶
A wearable-health startup wants to know whether its new fitness band is comfortable before committing to expensive injection-mold tooling. Rather than build a working device, they 3D-print a non-functional band and sensor housing at the exact intended geometry and weight, and have a dozen people wear it through a workday. The prototype is faithful on ergonomics — fit, pressure points, weight distribution, how it slides under a cuff — and completely silent on battery life, heat, and software, none of which exist yet. Testers report the clasp digs into the wrist bone at the smallest size. That finding is high-confidence because it is squarely inside what a physical mock-up can represent; the team revises the band curvature before tooling. Crucially, they do not conclude anything about durability or comfort-during-exercise, because the prototype cannot yet speak to either. Each result is tagged by whether the prototype's fidelity supports it.
How it works¶
- Draw the fidelity plan. Decide which behaviours the prototype will make real (geometry, weight) and which it will fake or skip (electronics, firmware).
- Build the cheap partial. Produce only enough of the system to exercise the targeted behaviours.
- Test for the targeted behaviours. Put it in front of real users or real conditions for exactly those dimensions.
- Tag each finding by fidelity. Label whether the prototype could genuinely speak to each result, and carry only the supported ones into the decision.
Tuning parameters¶
- Fidelity dimension — which aspects are made real: a looks-like model (form, fit) versus a works-like model (function). Each answers different questions and mistaking one for the other is the core hazard.
- Breadth vs depth — whether the prototype exercises many features shallowly or one feature deeply. Depth gives confidence on a narrow question; breadth surveys many at low confidence.
- Disposability — throwaway mock-up versus an evolutionary prototype meant to grow into the product. Throwaways are cheaper and franker about their limits; evolutionary ones risk inheriting shortcuts.
- Test realism — how closely test conditions match real use. More realism sharpens the reading but costs setup and can narrow how many testers you reach.
When it helps, and when it misleads¶
Its strength is surfacing real, physical, human surprises — a clasp that digs in, a flow no one can navigate, a part that cracks under a real grip — cheaply and early, before any expensive commitment. A vivid form of this is Wizard-of-Oz prototyping, where a human secretly stands in for not-yet-built functionality so a real user's reactions can be observed against a hollow shell.[n1]
Its failure mode is reading the prototype beyond its fidelity: treating a looks-like model as proof it works-like, or letting a prototype's silence on a dimension read as a pass. That is how prototype convenience hides deployment risk. The classic misuse is demoing a faked-backend prototype to leadership as evidence the system "works." The guarding discipline is to attach the fidelity caveat to every finding and to never let an untested dimension count as validated.
How it implements the components¶
approximation_method— the partial or low-fidelity build is the simplification: a stand-in artifact for the full system.validity_domain— the fidelity map of which behaviours the prototype can and cannot legitimately speak to.decision_requirement— the specific question (does the band fit comfortably?) sets which fidelity is worth building.uncertainty_expression— every finding carries its fidelity caveat rather than reading as a settled verdict.
It does not run a validation_check against full-scale outcomes — Policy Pilot does that through a real limited rollout — nor apply an exactness_escalation_rule, which Sensitivity Probe supplies.
Related¶
- Instantiates: Bounded Approximation — a low-fidelity build standing in for later system behaviour, read through its fidelity limits.
- Sibling mechanisms: Back-of-Envelope Estimate · Rough Order-of-Magnitude Estimate · Surrogate Model · Simplified Simulation · Algorithmic Relaxation · Policy Pilot · Sensitivity Probe
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Prototype Test operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it uses a partial or low-fidelity implementation as an approximation of later system behavior.
Independent corroboration: The frozen evidence defines Prototype Test as 'Uses a partial or low-fidelity implementation as an approximation of later system behavior', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Testing a partial implementation as an approximation of a later system is a core engineering-design practice.
Related originating lineages:
- Human-Computer Interaction — HCI independently canonized low-fidelity prototypes as instruments for usability and interaction learning.
Review resolution: Both blind reviewers agree on engineering_design as the primary origin. Explicit reconciliation resolves origin_mode_disagreement. The merged alternate lineages retain only domains the reviewers identified as materially formative; domain_reach=multi_domain records later applicability separately from origin breadth.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Wizard-of-Oz prototyping — a design-research technique in which users interact with what appears to be a working system while a hidden human ("the wizard") operates the responses. It lets a team observe genuine user behaviour against functionality that has not been built, and is a paradigm case of a prototype faithful on one dimension (the interaction) and entirely faked on another (the underlying engine). ↩