01 / UNDERSTAND
What is a Wizard of Oz prototype?
A Wizard of Oz prototype uses a person to perform a function that appears through a proposed system interface. The operator may interpret input, choose a response or simulate a capability that has not yet been implemented.
It lets a team examine an experience before building all the technology behind it. A successful session does not establish that the eventual system can deliver the operator’s performance.
Why use Wizard of Oz Prototype?
Some interactions are difficult to explore with static screens alone. A simulated response can reveal how people phrase requests, interpret feedback and recover when the system does not understand. The method is most useful when the team defines what is being simulated and keeps that boundary visible in its analysis.
When to use it
USE IT WHEN
The experience depends on a capability that is expensive or uncertain to build.
You need to explore input, feedback or recovery in a dynamic interaction.
A limited simulation can answer the design question without exposing participants to consequential decisions.
When to choose another method
Use Paper Prototyping when a sequence of interface states is enough.
Use Role Play when people and service roles should be openly enacted.
Use a technical experiment to evaluate accuracy, latency or scalability of actual automation.
What you’ll need
Define the learning question, participant task and simulated function. Prepare an operator interface or response set, consistent rules and an observation log. Explain that participants are using a research prototype with simulated capabilities and agree appropriate data handling. Debrief the role of simulation. Avoid real financial, medical or other consequential actions.
What the method needs
Keep the elements that help answer your question and support a decision.
What the participant can see and do.
The exact function performed by the operator.
Allowed inputs, responses, timing and exception handling.
Participant actions and operator decisions recorded together.
What the test says about experience and what it cannot say about technology.
02 / PUT IT INTO PRACTICE
How to build a Wizard of Oz prototype
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Choose one uncertainty
State the interaction question and the part of the system that will be simulated.
Test whether a repair request conversation gathers useful information.
02
Prepare the visible experience
Build only the interface needed for a credible task. Keep unrelated features out of scope.
A simple message interface can be enough for a focused conversation.
03
Constrain the operator
Define available information, response options and how to handle unexpected input.
The operator should not silently use knowledge the future system will not have.
04
Rehearse the session
Check timing, logging and communication between facilitator and operator. Try ambiguous and unsupported requests.
An exception response should be available before the first participant arrives.
05
Run and record
Observe how the participant responds while logging operator interventions and departures from the protocol.
Keep an especially helpful improvised answer visible in the record.
06
Debrief and separate findings
Explore expectations and clarify simulation. Distinguish interface learning from assumptions about future system performance.
Understanding a response does not prove a classifier can select it.
07
Define the next build or test
Use the evidence to change the interaction and identify the capability requiring technical evaluation.
Test recovery with realistic response limits before expanding scope.
Example: a repair request assistant
Fictional prototype: a person enters a household repair request into a simple chat interface. A researcher selects responses from a prepared set, asking for the affected item and a short description. The session uses a safe invented task and creates no real service request.
An unexpected description does not fit the response set. Instead of interpreting it perfectly, the operator uses a clarification prompt. The team observes whether the participant understands what information is missing.
A useful finding would concern the clarity of that exchange. It would not establish automated understanding, response speed at scale or safe handling of urgent repairs. Those require separate evaluation of the actual system.
03 / BELOW THE SURFACE
Below the surface: the operator can erase the problem
A skilled human can make an incomplete system appear more capable than the proposed implementation.
INFORMATION
What did the operator know?
Compare it with the future system’s available inputs.
INTERVENTION
Where did human judgement rescue the interaction?
Keep departures from the protocol visible.
RECOVERY
What should happen without that rescue?
Design a credible route through uncertainty.
The operator may infer intent from tone, remember earlier context or repair an ambiguous message without exposing the difficulty. That helpfulness can hide the very failure the design needs to address. Record the information and judgement behind each response.
After the session, identify which decisions used capabilities outside the intended system boundary. Revisit those moments with a constrained response and a visible recovery route. Do not assume the best human performance is the correct product baseline.
This editorial check turns the operator log into design evidence. It shows where the interface needs to acknowledge uncertainty rather than conceal it behind a convincing demonstration.
Wizard of Oz Prototype companion worksheet
The worksheet plans the simulated capability and operator protocol. Page two records an interaction, the operator’s decision and the limits of the resulting evidence. It supports a controlled research session, not deployment of a live service.
Practical tips
Rehearse unexpected inputs as well as the intended path.
Keep operator interventions linked to participant behaviour.
Common mistakes
Claiming technical feasibility from an experience prototype.
Allowing unrecorded operator improvisation.
Letting a participant rely on simulated output for a real consequential action.
What you’ll get
A better specified interaction and an explicit list of capabilities still to evaluate. Keep the simulation boundary attached to every finding shared with the team.