A Wizard of Oz prototype lets people try an interface while a human performs a function that has not yet been built. A participant might ask a travel assistant for a hotel recommendation; an operator prepares the response behind the scenes. The team observes whether the exchange makes sense before investing in automated recommendations.
The useful result is evidence about the interaction: what people ask, what they expect next, and where the design loses them. It is not proof that the future software can deliver the same answer, speed, or reliability. This guide keeps the method's definition, use cases, test setup, and examples separate so you can decide what your own study should establish.
What is Wizard of Oz prototyping?
Wizard of Oz prototyping simulates a system's behavior with a human operator, often called the wizard. The participant uses a visible interface while the wizard supplies a response or controls the next state. A facilitator introduces the task and an observer records behavior; in a small study, one researcher may cover several roles, but the responsibilities still need to be clear.
The name refers to the person operating the machinery behind the curtain in The Wizard of Oz. John F. Kelley's early research applied this approach to a natural-language calendar application. The original research record is a useful starting point for that history.
Unlike a fixed click-through flow, a wizard can respond to input the team did not anticipate. That flexibility is valuable for conversational interfaces. It also creates a validity risk: a skilled person can infer intent and repair mistakes more effectively than the planned system. Define the wizard's allowed behavior before using the results to make product decisions.
When is the method useful?
Use it when the interaction is important but implementing the underlying service would be expensive, premature, or uncertain. Examples include a voice assistant, a recommendation service, a robot's responses, or a concierge workflow that may later be automated. You still need participants who represent the intended users; a human operator does not replace user research.
For example, a team could ask whether people understand a booking assistant's clarification questions. It does not need to build a recommendation engine to study that question. It does need consistent example listings, a response script, and a way to show an unavailable option. If the research question is whether an algorithm ranks hotels correctly, the simulated conversation cannot answer it.
A paper prototype may be enough when the operator only swaps screens. A digital interface helps when realistic text entry, remote participation, or several response states matter. For a conversation with many branches, plan the chatbot prototype flow before deciding which branches require a wizard.
How to set up a Wizard of Oz test
The method's three essentials are a script, a participant, and a human wizard. Add a clear observation plan so the session produces more than an interesting demonstration.
- Choose one uncertainty. For a hotel assistant: can someone refine an unsuitable recommendation without abandoning the conversation? Keep payment and account creation outside this session.
- Write a response policy. List supported requests, clarification prompts, unavailable-result messages, and escalation behavior. The wizard must not invent a capability whenever a participant gets stuck.
- Prepare the visible states. Build the request, clarification, recommendation, and fallback screens. An interactive prototype in Mockitt can represent these states; the operator still supplies the unimplemented service.
- Rehearse with an observer. Check that the operator can read input, select a response, and reset between sessions. Record operator delays separately from participant hesitation.
- Run the task without coaching. Ask for a goal, such as finding a suitable hotel within a stated budget, instead of telling the participant which control to press.
- Debrief and record limits. Explain the simulated parts appropriately, resolve any misunderstanding about what was real, and distinguish user confusion from operator errors.
Handle consent, personal information, and any concealed operation through your research protocol. Do not collect real financial or health information merely to make a simulation convincing. Nielsen Norman Group's method guidance discusses the trade-offs of using a human to simulate complex functionality.
A useful session record includes the request, response given, response delay, participant reaction, recovery attempt, and resulting design decision. If the wizard goes off-script, mark that exchange instead of treating it as evidence for the planned product. A short pilot often exposes gaps in the script before participant sessions begin.
Examples: speech, robots, and a social-search service
A speech-interface thought experiment
A participant says, “Move tomorrow's appointment to the afternoon.” A hidden operator interprets the request and displays a clarification: “Which appointment?” The test can reveal whether that wording is understandable and whether the person expects a confirmation. It cannot establish speech-recognition accuracy, calendar permissions, or conflict detection.
A human-operated robot
Here the operator might select a greeting or movement while an observer watches how a person responds. Separate the social interaction you are studying from physical performance that only the final hardware and software can demonstrate. The image is useful because it makes the communication channels visible.
Aardvark and the distinction between people and automation
Aardvark was a social-search service. Its authors' 2010 social-search paper describes a service that routed questions to people who could answer them. That supports the broader lesson that the human service and routing interface can be studied separately. It does not, by itself, verify every story about a no-code Wizard of Oz launch, so do not use that story as evidence of a measured saving.
What to carry into the next prototype
Keep the observed language, misunderstood prompts, missing states, and response rules. Give the implementation team a separate list of assumptions the wizard handled manually. The next prototype should test those assumptions with increasingly realistic behavior rather than simply reproduce the operator's best performance.