Simple Prototype¶
Artifact — instantiates Core Model First
Embodies the core function or interaction in a low-detail form so the main logic can be tested early.
A Simple Prototype takes the one interaction a design is betting on and makes it tangible — something a person can actually try — while stripping away everything that isn't that interaction. Where a diagram or an explanation lets you reason about the core, a prototype lets someone do it, and behavior under real use is evidence that argument cannot produce. That is the one idea that makes it this mechanism and not a sibling: it converts the central function into the cheapest artifact that still lets a human enact it, so the make-or-break question gets a behavioral answer before any detail is built.
Example¶
A small team is building a language-learning app around one bet: that a tight loop of see a word in context → guess its meaning → get instant feedback is engaging enough to keep people coming back. Rather than build it, they cut a stack of paper cards and run the loop by hand with five strangers in a café — one team member plays the "app," flipping to the feedback card the instant someone guesses. No colors, no accounts, no streaks, no gamification; only the core interaction, embodied at almost zero fidelity.
Watching real people run the loop settles the bet in an afternoon. For vocabulary the guess-then-feedback rhythm genuinely holds attention — people ask to keep going. For grammar it collapses: guessing a rule from one example just frustrates them. That split is decision-relevant. It confirms the core loop for one content type, falsifies it for another, and tells the team exactly where the next layer of fidelity has to go — a different interaction for grammar — before a line of production code exists.
How it works¶
- Reduce to the single core interaction. Identify the one function the whole design depends on and discard the rest for now.
- Embody it in the cheapest medium that still lets someone act. Paper, a clickable mockup, a human standing in for the system — whatever makes the interaction real at the lowest cost.
- Put it in front of real users and watch. The point is observed behavior, not opinion; you are testing whether the core logic works, not whether people say they like it.
- Let the break points set the next layer. Where the prototype fails or surprises defines which fidelity to add next, and where.
Tuning parameters¶
- Fidelity — paper, to clickable, to coded. Higher fidelity tests more of the real experience but costs more and risks anchoring testers on polish rather than the core loop. Keep it as low as the question allows.
- Test-context realism — a lab, a café, or the actual environment of use. More realism surfaces true friction but is harder to stage.
- Interaction depth — how many steps of the core loop the prototype includes. More steps test more of the logic but blur which step drove a reaction.
- Tester selection — representative users versus convenience samples. The wrong testers produce confident, misleading signal.
When it helps, and when it misleads¶
Its strength is cheap, early, behavioral evidence about the single interaction the design lives or dies on — the kind of evidence that arrives too late if you wait for a finished build.
Its central failure mode is fidelity leaking into interpretation. A prototype that looks too finished gets mistaken for the product, and testers anchor on incidental surface — a color, a wording, a stock photo — instead of the core loop you were testing. The disciplined countermeasure is to keep everything except the core interaction deliberately crude; a Wizard-of-Oz prototype[n1], where a human secretly supplies the "smart" behavior, is the extreme form of this — it tests the interaction while building none of the machinery. The classic misuse is the "prototype" that is really a demo built to sell a decision already made, rather than to test one. The guard is to script each test around the specific decision the prototype must resolve, and to hold fidelity down everywhere the test isn't about.
How it implements the components¶
Simple Prototype fills the enact-and-test side of the archetype — it makes the core doable, not provable-on-paper:
core_relation— the central function or interaction is embodied in a form a person can actually perform, rather than described.decision_relevance_test— the prototype exists to answer whether the core interaction works well enough to change the build decision; a result that wouldn't move the decision isn't worth prototyping.refinement_path— where the prototype breaks or surprises defines which fidelity layer to add next and in what order.
It does not validate the core against a reference dataset — that belongs to Baseline Model — nor record the idealizing assumptions behind the design, which Toy Model and First-Principles Model carry.
Related¶
- Instantiates: Core Model First — Simple Prototype is the way the archetype's core is made tangible and tested through use.
- Consumes: Core Architecture Sketch names the modules and responsibilities the prototype embodies at low fidelity.
- Sibling mechanisms: First-Principles Model · Baseline Model · Minimal Causal Diagram · Stripped-Down Simulation · Minimum Viable Explanation · Core Architecture Sketch · Toy Model
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Simple Prototype operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it embodies the core function or interaction in a low-detail form so the main logic can be tested early.
Independent corroboration: The frozen evidence defines Simple Prototype as 'Embodies the core function or interaction in a low-detail form so the main logic can be tested early', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Representation, Specification & Plan — Simple Prototype includes features of a static representation, map, specification, schema, or prospective plan that externalizes information, but its defining operation is an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: A low-detail embodiment of core function for early testing is foundational iterative design practice.
Related originating lineages:
- Art & Aesthetics — Sketches and maquettes externalize form for critique.
- Education & Pedagogy — Education, assessment, and instructional practice supplies a parallel or contributing lineage for the mechanism's defining operation: embodies the core function or interaction in a low-detail form so the main logic can be tested early.
- Human-Computer Interaction — Low-fidelity prototypes test interaction logic before implementation.
- Organizational & Management Science — Process prototypes test operating assumptions before rollout.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: embodies the core function or interaction in a low-detail form so the main logic can be tested early.
Review resolution: The blind reviewers agree that engineering_design is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, domain reach disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain convergent because the combined evidence shows independent disciplinary development. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=false preserves the affirmative synthesis judgment where either reviewer identified one.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] A Wizard-of-Oz prototype has a hidden human perform the function the finished system would automate, so the interaction can be tested with users before any of the underlying machinery is built. It is the purest expression of a simple prototype's logic: embody the core interaction, build nothing else. ↩