Ordering Food With Voice UI
How my team and I at Dive Creative adapted restaurant service principles and rapid prototyping to design a voice UI food ordering experience
Context
My team and I at Dive recently had the the opportunity to think through how people might order carryout using a device like Amazon Echo or Google Home. We partnered with Bob Evans to design several proof-of-concept prototypes that explored this idea. With companies like Dominos, Wing Stop, and Burger King developing new ways of ordering food, it was our turn to imagine how Bob Evans’ customers might benefit from a new ordering channel.
From the start, the initiative was exploratory — meant more for assessing the feasibility and desirability of a voice UI and less for designing a market-ready product. We identified customer goals, then planned, designed, and tested solutions for each. This article will explain our process and what we learned along the way.
Learning the Fundamentals
Our process started with hitting the books. This was our first attempt at designing any type of conversational UI, so we began by reading up on some techniques and tips. Here are the highlights:
Purpose
A conversational commerce experience has specific purposes and values that are determined by the design. Through design, interactions improve accessibility and minimize failures — enabling users to achieve their goals quickly, simply, and hands-free.
Conversation Is the Interaction
Rather than inputting information with a finger or mouse, users make requests or answer questions and a voice UI responds accordingly. This pattern of requests and responses represents dialogue: the interface that guides users until their desired outcomes are reached. Therefore, dialogue should anticipate users’ requests, confirm them, and intuitively lead to the next action.
Tone & Perception
Conversations are more meaningful when people take turns, learn or gain something, and improve trust between each other. When talking with a UI, users will expect these things too as they make conversations seem natural. So, design the dialogue with a defined personality and a cooperative approach to conversation.
Best Practices
We found some really helpful design guidelines written by Amazon and Google. Here’s a summary:
Determining Design Objectives
With the fundamentals under our belt, we established 8 goals for our design:
- Provide customers with a quick, hands-free ordering experience
- Support both reordering past meals and ordering from the menu
- Enable ordering even when customers are busy, hurried, or multi-tasking
- Encourage customer loyalty via simple repeat orders
- Ensure the voice UI experience is more convenient and/or desirable than ordering on the phone or online
- Use technology to foster connections and drive sales with a younger market
- Represent the Bob Evans brand authentically
- Portray Bob Evans as a customer-centered, technological leader among other family restaurant chains
Most of these objectives were based on assumptions or general knowledge, but they were still helpful in exploring ways to help users and generate business value.
Predicting our users’ purposes when using this channel helped us decide on a personality that best fit the UI. Although customers would be ordering carryout, we still wanted to mimic a sit-down experience with the UI resembling a human waiter. We spent time eating out or calling in orders and studied how servers address their customers. Then, we channeled what we observed in how we wrote dialogue by choosing traits such as hospitable, genuine, warm, and family-friendly.
Defining Ordering Scenarios
Based on our design objectives, we listed all the ordering scenarios we could think of on a whiteboard. Most of the scenarios were based on Bob Evans’s existing channels (phone, online, sit-down), but some were unique to a voice UI. In total, we identified 8 scenarios, each representing a conversation thread with its own nuances and outcomes.
Next, we gave each scenario structure by outlining a high-level flow. Ordering food was a familiar task to us, so this was relatively simple to do. We weren’t worried about the minutiae of conversation yet, just the steps needed to guide users from initiating the Bob Evans skill to completing an order.
Laying out these high-level flows revealed 3 categories the scenarios could be sorted into:
- Quick Order: When users ask to re-order one meal saved to their account such as a most recent order or a single favorite
- Order From a Familiar List: When users ask for a list of recent orders or multiple favorites and select one to order
- Order From an Unfamiliar List: When users ask for a list of recommendations or menu options and select one to order
Sketching Dialogue
The flows provided a skeletal structure that we then layered dialogue on top of. In the beginning, we wrote out conversations on a whiteboard to keep ideation quick and low-fidelity. Our concern was the functional back-and-forth — how the voice UI would confirm users’ requests and lead them to the next step in each scenario. This way, we could set a “happy path” that the UI could redirect to in case of variations, errors, miscommunications, or unfulfillable requests. We designed additional dialogues once the happy path was as simple and efficient as possible.
Writing dialogue scripts required us to talk to ourselves more than we were comfortable with. Dialogue sounds differently than it reads, and we had many instances in which our writing, when read, sounded unnatural, too formal, or redundant. To overcome this, we constantly role played our conversations, trimming the fat until the UI said only what was essential. We also revisited how waiters interact with customers and used those conversations as cues for the flow and personality.
Documentation
To communicate our designs with Bob Evans’ Digital Team effectively, we diagrammed the flow of each conversation. Though voice UI interactions are never perfectly linear, we still represented them this way to emphasize the happy path; any “sub-paths” were diagrammed later in the document.
Each diagram had three layers of information:
- Functional Path: Steps that represent the back-and-forth exchange between the user and voice UI
- Dialogue: Actual conversation points that correspond with each step on the functional path
- Components: Classification of individual pieces of dialogue
Documentation helped us to ensure consistency from scenario to scenario. It also gave us the opportunity to think through the different ways users might utter requests or respond to questions.
Changing Direction
Through role playing with the Bob Evans team, we determined that some scenarios simply weren’t feasible or desirable for the voice UI channel. As we learned early in the project, voice interactions are meant to help users quickly and simply achieve their goals. Requiring users to choose a meal from a list of menu items or past orders all by voice required too much cognitive energy and didn’t really add value when compared to other channels. So we narrowed the scope to just the Quick Order scenarios, namely ordering a most recent order and ordering one favorite.
Consolidating Content and Features
Our next iterations were hyper-focused on simplicity and speed. We started by examining the dialogue and consolidating the amount of information and choices to only the essentials. For example, we no longer asked if users wanted to hear order details, but voiced them automatically as the order was confirmed (as seen below). Not only did this reduce steps, but it also gave users the necessary information without requiring them to make an extra decision.
Consolidating information even led us to limit what users could do. If users were to request changing their pickup location or payment method from what was used on their last order, the voice UI would instruct them to order online instead. Seleting a location or configuring payment without visual feedback was more trouble than it was worth, even if it frustrated some users that these features wouldn’t be supported. Not to mention, encouraging true repeat orders, without any setting changes, was better aligned with Bob Evans’ push for customer loyalty.
The Power of Prototyping
After refining, documenting, and vetting our designs internally, we worked with developers at Bob Evans to build a prototype for testing. It was important to simulate an authentic ordering experience with an actual voice UI device, but we didn’t want to waste time developing a fully-functional prototype. So, we used a prototype with hard-coded requests and responses that corresponded with testing scenarios.
Each participant was asked to imagine the following:
You’ve just arrived at home and don’t have enough time to cook dinner tonight, so why not get some carryout? Bob Evans is always a good go-to. Using your Amazon Echo, place an order for your most recent order or your favorite.
From there, participants triggered the Bob Evans skill and placed their order as they thought best. We made note of their behaviors, reactions, requests, and commands while they interacted with the UI and then asked them to reflect on the experience afterward. Here’s a summary of what we learned:
- Perception: Users inherently compared the voice UI to a person. They thought our design was faster and had less potential for errors, but lacked the warmth of human interaction.
- Multi-channel experience: Users wanted a physical order confirmation via email or text message.
- Interrupting: Several users attempted to interrupt because order details were too long.
- Asking for help: At any point in the process, users wanted to be aware of commands they could make.
- Additional features: Some users requested other features like order tracking, simple add-ons, and promotional messages.
Impact
User testing marked the end of this project. From it, we learned that the experience did have appeal for customers, especially younger ones wanting the ability to place reliable, on-the-fly orders. However, any further iterations would require more robust development which Bob Evans wasn’t prepared to invest in. So, we left them with recommendations and a final, revised script in the event they take it to market.
As for Dive, this project reinforced the power of prototyping, even when the only UI asset was a script. Frequent role playing and user testing had a powerful influence on the following:
- Simplicity and efficiency: Testing ideas helped ensure that even minuscule interactions weren’t cumbersome for users.
- Collaboration: Prototypes led to critical conversations with the Bob Evans Digital Team, ultimately resulting in a narrowed scope for the voice UI channel.
- Thoughtful writing: Designing a voice UI deepened our appreciation for clear, concise writing in all user experiences.
Overall, voice-controlled commerce is still very experimental. It has a long way to go before this way of ordering becomes commonplace, but it takes people who are willing to invest the time and energy to get there. For Dive, designing a voice UI experience around something as familiar as ordering food was a good introduction to the technology. We enjoyed solving the unique challenges Bob Evans had for voice ordering and hope we get to solve others soon.
