Wizard of Oz Prototype

Purpose

The Wizard of Oz Prototype simulates a functioning system by having a hidden human operator ("the wizard") manually perform what the technology would do. This lets teams test sophisticated interactions — AI responses, algorithmic recommendations, voice interfaces — without any development, getting real user reactions to the experience rather than the technology.

At a glance

• Group size: 3–6 (wizard + user + observer(s))
• Duration: 45 minutes
• Difficulty: Moderate to high
• Facilitation style: Controlled experiment with hidden operator
• Setting: Two connected spaces (wizard hidden from user) or a single space with a screen barrier

How to run

1. Define what the system does (10 min): Map the interactions the "system" should handle. Write a script for the wizard covering common user inputs and appropriate responses.
2. Set up the stage (5 min): Create a realistic interface for the user (a screen, a chatbot window, a physical device). Hide the wizard behind it.
3. Brief the wizard (5 min): The wizard must respond consistently and within realistic time constraints. Provide a cheat sheet of responses.
4. Run the test (15 min): The user interacts with the "system" naturally. The wizard responds in real time. An observer takes notes on user behaviour, hesitations, and reactions.
5. Debrief with the user (5 min): Reveal the wizard (optional). Ask the user about their experience, surprises, and frustrations.
6. Team debrief (5 min): What did the test reveal about the interaction model? What needs to change?

Materials needed

• Interface mockup (screen, chat window, or physical prop)
• Response script for the wizard
• Screen or divider to hide the wizard
• Observation template
• Timer

Pitfalls & common mistakes

• Wizard too slow: If responses take 30 seconds when the real system would take 2, the test is invalid. Time the wizard.
• Wizard too smart: A human wizard can handle any input. A real system can’t. Constrain the wizard to realistic capabilities.
• Revealing the trick too early: Users behave differently once they know. Consider not revealing until after the test.
• No observation protocol: Without structured notes, you lose the data.

Inclusion & accessibility

• Ensure the mock interface is accessible (readable fonts, adequate contrast).
• If the test involves voice interaction, provide a text alternative.
• Brief the wizard on inclusive language and response styles.

Variations

• Remote Wizard of Oz: The wizard operates from another location via chat or remote desktop.
• Partial Wizard of Oz: Some functions are real, some are wizarded — useful when part of the system already exists.
• Longitudinal Wizard of Oz: Run the test over several days to capture habitual use patterns.

When NOT to use this

• When the core question is about technical feasibility, not user experience.
• When the wizard cannot reasonably simulate the system’s behaviour (e.g., real-time video processing).
• When deception of the user would violate ethical guidelines or trust.

Source & further reading

• Kelley, John F. — "An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications" (PhD thesis, Johns Hopkins, 1984)
• d.school, Stanford — "Wizard of Oz" prototyping exercises
• Buxton, Bill — *Sketching User Experiences* (Morgan Kaufmann, 2007)