Make it possible to order ahead with the Google Assistant
✦ Problem ⋯ How do we translate the familiar in-person coffee ordering experience of a "usual" at Starbucks to a Google Assistant action?
✦ Role ⋯ UX Writer, Conversation Designer
✦ Deliverables ⋯ Use cases, Dialogs, Error handling
✦ Tools ⋯ Google docs, Tableau, Sketch
Project timeline and my place in it
My efforts were focused on a 3-month design phase of the project. The Starbucks Google action launched during the 2018 holiday season. I was selected for this project because I owned the team's product voice and tone guide and had lead efforts to keep UX copy consistent across Starbucks’s customer-facing digital products.
While I was already familiar with UX writing and the necessary brevity, focus on action, and the conversational tone of in-app language, I had to quickly learn how to translate that to a voice experience and voice assistant turn-taking.
The working team included a Starbucks emerging tech Sr. Product Manager, Google account managers, a Google voice designer, and Google engineers.
Skills and tools used
I wrote dialogs in Google docs and used Sketch to capture the conversation for the Google Assistant GUI experience. This was a highly collaborative project that spanned teams, companies and locations. It required flexibility and teamwork.
A bit on how we got there
Working with a Google voice designer, I created principles for a good conversation between a barista and a customer.
- Provide just enough information (quick and easy)
- Be honest and clear (no unexpected motives)
- Be relevant to what’s at hand (context)
- Be polite and helpful (like a barista would be to a customer)
To capture the most natural phrasing and turn-taking, I analyzed ~15 hours of recorded drive-thru conversations between baristas and customers in Washington State. From this, I captured common phrases, conversation turns, and moments of clarification. I put in this extra effort to capture how customers naturally ordered products so I could build a case and provide evidence that an intuitive ordering experience needed to account for the complexity of the Starbucks menu. The system would have to disambiguate synonyms for products and customization that were outside the original system grammar.
I synthesized my findings into 7 guiding dialogs covering expected ordering scenarios. They helped shape the system requirements and helped us talk through feasibility and product tradeoffs.
- Happy path ⋯ Customer orders their usual single-item at a store they go to regularly.
- Reorder + store details ⋯ Customer gets a usual but may go to different stores regularly and needs extra details about the pickup store
- Reorder + add money ⋯ Customer gets their usual but doesn’t have enough money on their Starbucks Card/account to cover the order and needs to add money
- Recommendation ⋯ Customer wants to order something that’s not their usual
- Freeform order + store details ⋯ New or non-regular customer who doesn’t have a usual order or a regular store
- Freeform order + additional item ⋯ Customer wants to order something that’s not their usual and adds another item to the order
- Drink customization ⋯ Customer wants to make a change to the drink (milk choice, # of shots, syrups, etc)
I worked with an expert Google voice designer workshopping the dialogs. As we worked through the dialogs, I created additional deliverables to help strengthen the UX:
- Most common ordered products and customizations
- Common synonyms for products (i.e. drip coffee, snack box, etc)
- Synonyms for customizations (regular milk, dash of peppermint, etc.)
- Common synonyms for Starbucks-specific menu items and sizes
Takeaways and what I learned
I learned to go deeper into user flows: branching and accounting for more conditions than in a typical GUI design.
Strategically, this project inspired me to think about ways to incorporate ordering a usual across digital experiences because it was an existing and familiar mental model.
The most important takeaway was how our success depended on building trust across disciplines and staying flexible and realistic about what could be done within technical language processing constraints.
