Wizard Of Oz Prototyping

Version

v1 · 2026-08-24 · History

Prime #

1276

Domain group

Professional & Organizational Practice

Origin domain

Human-Computer Interaction (HCI)

Subdomain

Design Research → Human-Computer Interaction (HCI)

Aliases

Woz Prototyping, Oz Testing

Core Idea

Wizard of Oz prototyping decouples what a system appears to do from how it actually does it, replacing the planned interior with a concealed human operator (or kludge) during user-facing trials. The user interacts with a convincing surface while a person supplies the behaviour, so the team validates the experience and demand — not whether the interior can be built — before paying the build cost.

How would you explain it like I'm…

The Pretend Robot

Imagine a 'magic' robot that answers your questions, but really there's a person hiding behind a curtain typing the answers. You think you're talking to the robot, so you act for real — and that helps the builders learn if people would even want the robot before they build it. The hiding part is what makes you act naturally.

Fake Robot, Real Person

Wizard of Oz prototyping means making something look finished on the outside while a hidden person (or a quick cheat) does the work on the inside that the real machine would do later. Users interact with what seems like the real thing, so they behave honestly, and the team finds out whether people want it without paying to actually build the hard part. The fake has to act like the real machine would — if the real one would be slow on big jobs, the hidden person has to be slow too — because that's what decides what the test actually proves. And the hiding matters: if users knew a person was behind the curtain, they'd act differently, so the secrecy is what makes the data real (and also raises questions about being honest with people).

Fake the Inside, Test the Outside

Wizard of Oz prototyping is the move of decoupling what a system appears to do from the outside from how it actually does it on the inside, by replacing some or all of the planned interior mechanism with a hidden human operator (or an off-the-shelf shim, or hand-rolled scripts) during user-facing trials. The user interacts with what looks like the target system while, behind the curtain, a person or a kludge supplies the behaviour the real mechanism is meant to produce later. The defining commitment is that the validation question is about the experience, the demand, and the interaction design — not about whether the interior can be built. Three facts give it shape: interior–exterior decoupling (the surface can be made convincingly present while the interior is deliberately absent); the substitute must behave like the planned interior within a bounded envelope (anything a user could observe must come from the substitute, so a mechanism that would be slow on long inputs requires the operator to delay on long inputs), and that fidelity determines exactly what the trial validates; and concealment is load-bearing (if the user knows a human is behind the curtain, they become a collaborator rather than a test subject, changing the data — which is also what raises the ethical and disclosure questions).

 

Wizard of Oz prototyping is the structural move of decoupling what a system appears to do from the outside from how it actually does it on the inside, by replacing some or all of the planned interior mechanism with a hidden human operator (or an off-the-shelf shim, or hand-rolled scripts) during user-facing trials. The user interacts with what looks like the target system; behind the curtain a person — or a kludge — supplies the behaviour the planned mechanism is meant to produce later. The defining commitment is that the validation question is about the experience, the demand profile, and the interaction design — not about whether the interior can be built. The team buys information cheaply by skipping the expensive build, the user supplies honest interaction data because the surface is convincing, and the team learns whether the planned system is worth building before incurring the build cost. Three structural facts give the pattern its shape. First, interior–exterior decoupling: any system has a surface (interaction, interface, promised function) and an interior (the mechanism that delivers it), and the move exploits that the surface can be made convincingly present while the interior is deliberately absent. Second, the substitute must behave like the planned interior within a bounded envelope: whatever a user could plausibly observe from the surface must come from the substitute, so a mechanism that would be slow on long inputs requires the operator to delay on long inputs, and one that would refuse out-of-scope requests requires the operator to refuse — the fidelity of the substitute determines exactly what the trial validates. Third, concealment is load-bearing: if the user knows a human is behind the curtain, the data changes — users become collaborators rather than test subjects — so concealment is what produces honest demand data and also what raises the ethical and disclosure questions the protocol must handle.

Broad Use

• Human-computer interaction (the origin): a hidden operator types responses while a user converses with an apparently automated interface.
• Intelligent-system development: a human in the loop produces the "model's" output so the team learns desired behaviour and latency tolerance first.
• Service and customer-experience design: manual labour behind the counter validates the customer journey before the operational build-out.
• Organisational pilots: a new process runs with manual handoffs and spreadsheets before the system to automate it is specified.
• Robotics: a planned autonomous machine is tested with a hidden teleoperator to validate social interaction and demand.
• Venture discovery: the "concierge" and Wizard of Oz patterns — an apparent automated product with a manual back end — validate demand before building.

Clarity

Disciplines the team to be explicit about which interior is faked, what the operator may do, and what disclosure applies, and separates build-validation ("can we build this?") from experience-validation ("does this experience produce the demand we need?").

Manages Complexity

Compresses an expensive integrated build-and-test cycle into a cheap experience-test, and produces a staged-commitment ladder — surface only, then surface-plus-substitute, then hybrid, then full system.

Abstract Reasoning

Licenses inferences invisible to "build and test": run the demand-test before the build-test, match the substitute's envelope to the planned envelope, and treat fidelity as a control variable chosen against the validation question.

Knowledge Transfer

• Interface to service design: the staged-commitment ladder becomes service-blueprint validation with a manual back-of-house standing in.
• Lean practice to venture: the "concierge" and Wizard of Oz patterns inherit both the structural move and the ladder.
• Robotics to operations: a hidden teleoperator behind apparent autonomy maps onto spreadsheet handoffs behind an apparent workflow system.

Example

A startup validating a meal-planning service runs a polished web app whose "algorithm" is the founders hand-assembling plans from a spreadsheet; renewal rates answer whether subscribers value the plans before the recommendation engine is ever built.

Relationships to Other Abstractions

Current abstraction Wizard Of Oz Prototyping Prime

Parents (1) — outgoing typed relations

• Wizard Of Oz Prototyping is a kind of, typical Design Prototyping Prime

  Ordinary design_prototyping builds a REAL but partial interior; wizard_of_oz specifically FAKES the interior with a concealed substitute and aims validation at experience not buildability.

Children (1) — abstractions linked here by typed relations

• Wizard of Oz experiment Domain-specific is a kind of Wizard Of Oz Prototyping

  It is the named instance of the prime pattern: a hidden human operator supplies the not-yet-built system while the interface is presented as autonomous.

Hierarchy paths (2) — routes to 2 parentless roots

• Wizard Of Oz Prototyping → is a kind of, typical Design Prototyping → presupposes, typical Iteration

Show alternative path (1)

Not to Be Confused With

• Wizard of Oz Prototyping is not Design Prototyping in general because ordinary prototyping builds a real but partial interior to test feasibility, whereas this fakes the interior with a concealed substitute and aims validation at experience.
• Wizard of Oz Prototyping is not a Minimum Viable Product because an MVP's interior genuinely works at minimal scope, whereas the Wizard of Oz interior is faked and unsustainable by the real system.
• Wizard of Oz Prototyping is not Signaling because signaling courts an audience with a costly-to-fake indicator, whereas here concealment exists to elicit honest demand data from a participant who is misled, not courted.