Wizard of Oz Prototyping | HCDE 451

Video Prototype

Wizard of Oz Prototyping

Our task was to create a Wizard of Oz prototype. In this method, you create an interactive, believable experience between a person and a device. In reality, the designers are pulling all the strings in the background that allowed for real-time modification. This methodology is also helpful because you can quickly learn and iterate on a design in response to a question.

A drawing that depicts Wizard of Oz prototyping

Our Prototype

For our assignment, we designed to design interactions with a voice recognition software that was conversational and responsive.

We prototyped CookBuddy, a voice-controlled app that operated through a speaker like Google Home or Amazon Echo.

It enables a user to:

  • Name the ingredients they want to cook with i.e. “What can I make with — -?”
  • Choose a recipe from a list of suggestions
  • Receive a list of ingredients

In other words, our system could take in a list of ingredients, suggest three recipes, and list the ingredients of the user’s chosen recipe. We created this app for users who want to cook but don’t know what to make.

To create this system, we pre-recorded the lists of ingredients, recipe combinations, and the welcome message. During our usability test, we presented a range of ingredients (apples, cinnamon, eggs, bread, etc) and asked them to pick up to 5. We played CookBuddy’s pre-recorded responses from a Bluetooth speaker, and we taped it to an Arduino with a row of lights that provided feedback about when CookBuddy was listening. One of our team members was in the room when we conducted the test, and he played the correct combination of ingredients or the recipe depending on what the user chose.

Top view of CookBuddy
Side view of CookBuddy and its Bluetooth speaker

Our criteria for a successful prototype were the following:

  • The user is able to successfully complete the task given to them.
  • The user finds the process of obtaining a list of ingredients from a meal choice to be intuitive.
  • The prototype realistically mimics the affordances of a new application that uses a voice-operated assistant.

We tested our prototype with 4 students who lived in a fraternity. We collected the following data:

  • Video footage of participants will record the interactions and scenarios with the behavioral prototype.
  • Notes taken during the sessions will focus on participant interactions, pain points, and any useful metrics for the tasks.
  • Post-test debrief with the participant to obtain feedback about our prototype and ascertain how believable it was.

After the user completed their tasks, we asked a few follow-up questions:

  • How was your experience with CookBuddy?
  • Tell me about your experience with the voice-recognition software
  • Would you use this app in real life?
  • What improvements could we make?

Here’s a video of our user tests: https://www.youtube.com/watch?v=PIHQAnMKJMg

Results from User Tests

Overall, all 4 users thought that we created a believable experience, and they said that they would use it in real life. They thought that CookBuddy’s time to respond was a little slow, but it aligned with their expectations of other voice assistants like Alexa or Google Home. They also liked that there was a simple user flow and that they could be conversational while completing their task.

In terms of room for improvement, users wanted to have a clear invitation to the next step after the voice interaction. They also wanted to only say part to say part of the recipe name i.e. “let’s make pancakes” versus “let’s make cinnamon apple pancakes.”

Limitations & Future Work

Overall, we successfully created a Wizard of Oz prototype that mimicked the affordances of voice recognition software.

Because we tested our prototype with 4 white men, we know that their responses do not reflect the needs, expectations, and preferences of the entire population. If we kept developing this device, we should test CookBuddy with potential users of different ages, levels of cooking experience, and food preferences.

Based on our user testing, we’d make the following changes:

  • Ensure that CookBuddy recognizes the recipe is the user only says part of the recipe name i.e. “egg sandwich” versus “egg salad sandwich.”
  • Prototype the rest of the experience so the user receives the recipe on the phone and can take it for the grocery store.
  • Enable the system to recognize dietary restrictions or omit recipes with certain ingredients. This is especially important for users with food allergies or intolerances, or users who have dietary restrictions because of their religion.

Writer at Microsoft | Human Centered Design and Engineering Alumna | Lifting as I climb | www.aleenahansari.com