Wizard of OZ Prototyping: All the Basics You Need to Know
One of the biggest challenges for designers is saving time and resources when testing a design. Many experienced designers rely on prototyping frameworks to get the prototyping job done. The Wizard of OZ prototyping is one of those frameworks designers use to test designs.
If you're hearing about the Wizard of OZ prototyping for the first time, then keep reading. This blog provides a brief introduction to Wizard of OZ prototyping and its use cases.
According to an estimation, a single dollar invested in UX can help you get an ROI of 9,900%. But the problem is that businesses cannot spend a lot on UX to create better products. They have to work with teams of efficient designers who can create and test different designs to choose which one works the best.
Wizard of Oz prototyping allows designers to fake the functionality of a design they want their users to test. This technique allows designers to avoid investing time and money to create functionality. Another additional benefit is that designers don’t have to find users to test different designs.
And yes, you’ve guessed it right. The name of Wizard of Oz prototyping is inspired by the movie of the same name. While working at Johns Hopkins University, Dr. Jeff Kelley developed the “Wizard of Oz” experimental technique.
He mentions that he was inspired by the scene in the movie when Toto pulls back a curtain, revealing that the wizard isn’t a magician but a pun operating machine.
Wizard of Oz prototyping is used in digital systems. The user who tests the system thinks they are dealing with a computer-driven wizard who is managing a system. However, they are interacting with a human-controlled system behind the scenes.
The common motive behind using Wizard of Oz prototyping is to complete a project efficiently. A team of designers starts working with Wizard of Oz prototyping after agreeing on whether they want to test or explore something new.
For example, if a team wants to test a new design process that requires tons of coding, they can switch to Wizard of Oz prototyping. This technique allows them to fake functionality and test the feedback of the users.
The good thing about Wizard of Oz prototyping is that it allows the creation of a rudimentary model. Developers can use everyday objects that represent a sample working model of a product.
On the other hand, developers can also develop a model to perform the tasks that the final product is expected to complete. The next step is using role-playing to estimate the ideal interaction of users with the product.
This fake functionality of a Wizard of Oz prototyping system, whether achieved through everyday objects or a model, is needed to streamline the UX development process.
There are three pillars of any wizard of oz test:
- A Tester
- A Human Wizard
The script is what allows the Wizard of Oz prototyping to perform. Using the script, it becomes easier for developers to create a prototype that doesn’t skedaddle from the given instructions. There are no automatic changes to the script.
A tester is a person who analyzes the activity performed by the script. The presence of a human tester makes it easier to avoid the presence of many human testers. In an ideal Wizard of Oz prototyping workflow, the tester doesn’t have to see all the actions that the script can perform.
The wizard is the human-controlled system that performs actions according to the script. The tester thinks as if they are dealing with a wizard. But in reality, they are dealing with a person that is handling instructions according to the instructions behind the scenes.
Here are a couple of wizard of oz prototyping examples easier to understand how the process works:
A Thought Experiment
A person (tester) might be given a computer system that incorporates a speech interface. The user might think they are communicating with a system that can understand human interaction. The speech is directed to a wizard sitting in another place that communicates with the tester.
A Business Example
Aardvark was a social platform that allowed people to get the best answers on a given topic. The Aardvark team had to go through a tedious process to write code to understand the user’s reaction. Instead of coding, they developed a team of people who acted as the wizard and provided the answers to questions. Doing so allowed them to understand their workflow without investing in development.
Creating a team of professionals instead of developing a computer-driven model is way more effective from a business point of view. By using the Wizard of Oz prototyping technique, businesses can develop models to predict user behaviors without investing in coding. You can use the Wizard of Oz prototyping to save your time and effort and get to model different UX workflows in a short time.