Wizard of Oz

The Wizard of Oz (WOz) method can be seen as a form of performative prototyping that entails a designer assuming the role of the ‘wizard’ who simulates much of the functionality and interactivity of a project. This method can enable designers to refine user interaction with a project without needing it to be fully functional, which means that less time and money needs to be invested in producing functional prototypes simply for testing purposes. The method was first described by researcher John F. Kelley¹ during the 1980’s and has since seen uptake in a variety of research fields, which reflects the method’s versatility and ease of use. While the WOz method is relatively commonplace in interaction design for digital environments (screen-based projects) it has also been employed successfully as part of an iterative design process for tangible and physical media, which again reflects how versatile the method is, making it a powerful tool for any interaction designer.

When using the method to test a screen-based project, the ‘wizard’ and participant are often kept in separate locations so as not to break the ‘illusion’ of a fully functional prototype. During testing, the wizard will simulate interactions in response to participant actions, which are usually relayed to the wizard via screen sharing or other video software. The wizard may assume a variety of roles, such as simulating an ‘intelligent’ system, course-correcting and potentially overriding user decisions as well as simulating sensory data to ensure the user experience feels complete. While separation of wizard and participant makes sense for screen-based projects, when using the WOz method to test tangible or physical media projects it is often necessary for the wizard to be physically present to ‘pull the strings’ of their project. In these situations, ‘sleight of hand’ can be used when demonstrating the interactions of a tangible media project, for example, manually triggering an LED to blink when a user performs a particular interaction, implying that their action has resulted in the LED blinking.

Whether you use the WOz method for screen-based or tangible media interaction projects, consistent responses from the wizard are fundamental to ensuring the ‘illusion’ you’ve created isn’t broken by your participant. Ensure timing, patterns of response and the underlying system logic are all consistent and consider rehearsing a few use-case scenarios before putting on your wizard hat!

Activity

Before you start

With your project team, agree on your aims and goals and develop a list of questions you want to test out with your participants. Organise these questions in order of importance and use this list to inform how you produce your prototype. You may be testing a specific part of the project or an early version of the entire project – either way it’s important to be realistic about what you can achieve in the time you have available. Produce a prototype or series of prototypes that make the most of readily available materials, such as cardboard, paper and other lo-fidelity prototyping formats. Consider how you can augment these prototypes using smartphones and laptops. Identify and recruit your participants – ideally these would be prospective users. If you don’t have access to these people, friends and peers are a good substitute as this gives you an opportunity to gain informal feedback on your project while also testing out how to run a WOz testing session. Prepare your prototypes, assign roles and rehearse your testing scenarios, making changes to actions, responses and roles until your intended experience has been created. Finally, prepare your testing space and ensure that it meets your team’s requirements.

Activity steps

1. Begin your scenario by introducing participants to the project and ensure they’re sufficiently briefed on the project with enough context to understand what’s expected of them. Enact the scenario – the wizard/s will simulate functionality in the prototype to varying degrees and remain hidden from the user.
2. While the wizard/s operate the prototype, observers will record a list of findings such as errors, ideas, issues and anything relevant to the aims of the testing session.
3. If possible, make some adjustments in real time, where the observers share brief insights with the wizards, make changes to the scenario as relevant and then integrate these changes into a new scenario and begin the test again.
4. Once all of your scenarios have been enacted, reveal the wizard/s to the users and have a brief discussion with them about what did and didn’t work. Record any of these findings and add these to the points taken by the observers.
5. In your team discuss the findings from observers, users and anything else uncovered throughout the testing process. Reflect on and integrate relevant findings into future iterations of the project.

References

1. Kelley, J. 1984. ‘An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications’. ACM Transactions on Information Systems (TOIS) 2 (1): 26–41. https://doi.org/10.1145/357417.357420.