Wizard of Oz
Also known as: WOz, Wizard of Oz Prototyping, Hidden Operator Simulation
The Wizard of Oz method is a prototyping and evaluation technique where users interact with what appears to be an automated system, but behind the scenes, a human operator (the wizard) controls the system's behavior. Developed by John Kelley in 1984, this method is especially valuable for exploring novel interaction paradigms (voice interfaces, AI assistants, gesture-based systems) before full implementation. By simulating future system capabilities, researchers gain insight into user expectations, mental models, and requirements without building the complex automation first.
Key highlights
- Enables rapid exploration of novel interaction paradigms before expensive development investment.
- Users reveal authentic expectations and goals through interaction; more realistic than interviews or surveys.
- Captures edge cases and use cases that designers may not anticipate.
- Cost-effective compared to building partially automated or fully automated prototypes early in design.
Intuition
This section is available to Pro members. Upgrade to Pro
How it works
This section is available to Pro members. Upgrade to Pro
When to use it
Use Wizard of Oz early when exploring novel interaction paradigms (voice, gesture, AI chatbots) to avoid premature commitment to specific automation approaches. Ideal for defining requirements for complex systems where user expectations are uncertain. Do not use as a substitute for full usability testing; validate prototypes and final systems with genuine users.
Strengths & limitations
- Enables rapid exploration of novel interaction paradigms before expensive development investment.
- Users reveal authentic expectations and goals through interaction; more realistic than interviews or surveys.
- Captures edge cases and use cases that designers may not anticipate.
- Cost-effective compared to building partially automated or fully automated prototypes early in design.
- Human operator introduces variability; responses may be inconsistent or unrepresentative of actual system performance.
- Latency and operator errors may frustrate users or create false expectations about system speed and reliability.
- Requires skilled operators who understand system domain and can respond appropriately.
- Findings are specific to simulated interaction paradigm; results may not generalize to fully automated system.
Common pitfalls
This section is available to Pro members. Upgrade to Pro
Applications
This section is available to Pro members. Upgrade to Pro
Frequently asked
How do I write a good briefing for participants without revealing the wizard?
Say: 'You will interact with a new system designed to [goal]. We are interested in how you use it and what you expect.' Avoid technical terminology that might suggest automation. Do not say 'AI' or 'automated' unless the system would realistically advertise this.
What should I do if a user explicitly asks if there is a person behind the system?
Answer honestly (per your IRB protocol) and apologize. Explain this is a research method to explore user needs. Continue the interaction if the user consents. Note that they know about the wizard when analyzing data.
How many users do I need for Wizard of Oz?
6–15 is typical for exploring interaction patterns. More users reveal variance and edge cases. Stop when new participants' interactions are similar to earlier ones (saturation).
Sources
- 1.Kelley, J. F. (1984). An iterative design methodology for user-friendly natural language office information applications. ACM Transactions on Information Systems, 2(1), 26–41.
- 2.Maulsby, D., Greenberg, S., & Mander, R. (1993). Prototyping an intelligent agent through Wizard of Oz. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (pp. 277–284).
You have read it. What now?
Cite this page
ScholarGate. (2026, June 3). Wizard of Oz. ScholarGate. https://scholargate.app/human-computer-interaction/wizard-of-oz