Process - CUI Prototyping for Healthy Food Delivery



My role: Project Manager

Techniques used: Competitive analysis, analogous domain research, scenario generation, conversation flows, script writing, video production

Duration: 3 weeks (February 2017)

Project prompt

Our prompt for this project was to research and prototype a novel conversational user interface (CUI) for meal ordering and delivery.

What we delivered

Carrie is a CUI to help people with dietary restrictions order meals for delivery. To accompany our final pitch of the design, we created a video acting out a scenario of the user’s experience ordering with Carrie.

Teammates: Danny Choo and Annie Kim


Accounting for State of Current Tech

To kick off our project, we first looked into the capabilities of current conversation user interface (CUI) systems. At the time of this project, there were three major CUIs on the market: Alexa, Google Home, and Siri. Through reading about their capabilities and testing out each of the systems, we uncovered several strengths and weaknesses of CUI platforms that informed our designs moving forward.


CUI Strengths

  • Largely function without a screen, making them less distracting than other forms of interaction
  • Hands-free capabilities allow users to use them while doing other things i.e. cooking, driving, packing
  • Strongest when they can integrate with third party apps or devices, such as Google Home bringing up Youtube videos on your TV, or Alexa adding items to a shopping list

CUI Weaknesses

  • Commands require specific syntax or keywords that are hard to recall
  • CUI assistant has an inconsistent tone, especially on Google Home
  • Limited question and answer capabilities
  • User often needs to invoke the wake phrase, such as "Alexa" or "Ok Google," every time they want to give a command, which can be repetitive and detract from the feeling of a conversation 


We also looked at tech-enabled food delivery services, which are growing in popularity. Many delivery platforms like Seamless, GrubHub, and Postmates give users as wide an array of options as possible, which can leave users paralyzed by choice. Other restaurants, like Domino's, are exploring CUIs as a way of speeding up the ordering process. We observed people using these apps to order food for delivery and noticed that a major frustration was the number of choices along the way. A CUI would be a perfect way to offer guidance and personalization in the food ordering process.


Idea Generation

After our initial research, we generated over 20 scenarios of possible future solutions that could utilize the strengths of CUIs while also solving food delivery issues. Our scenarios addressed the problem, how a user would interact with the CUI to solve it, and the final outcome - eating delicious food!


Several themes cropped up in our scenario generation:

  • Dietary restrictions and menu personalization
  • Amount of information offered by the CUI, whether it's toppings, coupons, or delivery times
  • Push back from the CUI if it knows something the user does not

We decided to focus on a CUI that could personalize options to the dietary restrictions of the user. Food allergies and dietary restrictions keep many people from eating out or ordering food. A CUI that could pull from multiple sources and give users personalized recommendations would be a huge opportunity for food lovers and restaurants.


Mapping the Conversation

Before jumping into writing a script for the CUI, we first mapped out the general flow of the conversation. We ran through several scenarios, pulling from what we know about CUI technology and food ordering, to design a general flow that could cover a number of use cases. We wanted to be sure to control the amount of information given to a user at any time, while also allowing the user to make decisions along the way. 

A major aspect of this system is that it can keep users on track if they are on a diet. We built in specific moments of push back if the user requests additional items that do not fit into their profile. Users are still able to override these controls if they want, but a moment of confirmation may make users think twice about ordering that extra cookie.

Conversation flow v1.jpg

Prototyping Without an Interface

CUIs, like many emerging technologies, require out-of-the-box thinking when it comes to prototyping. We tried a series of techniques to develop the script and test out the concept of Carrie, including role playing and experience prototyping.


Assistant Personality

It was important to us that Carrie have a personality that would be friendly but firm in instances where it needed to push back. We explored different personas by role playing in various scenarios. One team member would be the user, the second would be Carrie, and the third would take notes on the dialogue. We tried out different personas like informational assistant, sassy friend, and personal trainer to see which would be the most effective. Ultimately, we took aspects of informational assistant and sassy friend to create the persona for Carrie.


Audio Cues

With our dialogue fleshed out for several paths through the scenario, we wanted to make sure the experience would feel as authentic as possible for our prototype user. We envisioned the user conversing with Carrie through an earbud to ensure privacy, since we are dealing with sensitive dietary information. Because the earbud would not allow for visual feedback, we wanted to give the user other types of cues for when the CUI is listening and when it is thinking. We picked out two sounds that could embody those cues for the user.


Experience Prototyping

We planned for Carrie to be a hands-free experience, and wanted to be sure users could carry on a conversation while doing another task. We asked users to build a house out of popsicle sticks as they used our prototype to simulate that experience.


We received some very helpful feedback during experience prototyping, that helped us round out the error prevention and recovery aspects of Carrie. One design choice we had made is that Carrie is a continuous conversation. This means that rather than needing to hear the prompt before every user input, Carrie is waiting for the user’s response. This presents issues if the user is interrupted or needs to pause the conversation. In this case, we added a prompt from the user (“Carrie, hold on”) that pauses the conversation and saves the order until the user is ready to return. This became a central focus in our final pitch.


Sharing the Vision

Without the time or current technology capabilities to make Carrie a reality, we made the short video at the top of this page to share our vision of what Carrie could be. 

We developed a script based on our experience prototyping feedback and the key value propositions for Carrie:

  • Offer personalized food delivery options based on the user's profile
  • Integrate with third party apps to create additional value i.e. WeightWatchers
  • Keep Carrie hands-free and discrete by using an earbud
  • Utilize the flow of natural conversation and seamlessly handle interruptions
  • Push back to keep users on track if they try to order items that are out of the bounds of their restrictions

The visuals of the video had to match these value propositions as well. I storyboarded the entire shoot based on the script we created. We only had two days to develop, shoot, and edit the video, so we kept it to still photographs. This allowed us to focus on the audio, which was the most important aspect of the concept!


The final video shows a use case for Carrie and the three main strengths that we uncovered in our research. This video was used to communicate the idea to stakeholders and get feedback from potential users.


Hands free

Pause & save when interrupted

Keep users on track


Next Steps

Ultimately, this project was a way for us to devise useful applications and explore prototyping a conversational user interface. The next step in this process would be to build out conversation segments and start testing with real data.

In order to build Carrie, we would need to explore in more detail the existing APIs from Yelp or Google that may already contain the information about restaurants that we need - location, delivery services, menu, prices, and ingredients. If the data does not exist already, we would re-evaluate all the pieces of information we wanted to include, and perhaps devise ways to gather that information ourselves.