Building a Google Home Bot: Conversational UI

How to design a bot you actually want to talk to

Liz Wells
Team Stink
8 min readJun 22, 2017

--

This article covers conversation design and the VUI part of a prototype I helped build with coworkers from Stink Studios at Google NY during the three-day Actions on Google Workshop. To learn more about the idea, read our introduction article here, or to learn more about the technical side of things, read Arnaud’s article here.

Understanding Your User

After figuring out an idea for a Google Home bot, the next step is thinking about the context in which the user will interact with the bot. Yes, a user will speak to it, but when will the interaction occur and what else will they be doing? How does the bot fit into a user’s life?

If the idea is a recipe bot, the user should be able to clearly understand instructions while doing multiple things in the kitchen. Creating a bot for this kind of scenario is an ideal use for the Google Home because it thrives in a fast-paced, hands-free environment. Because the user is thinking about other tasks (chopping vegetables, watching water boil, etc.), the instructions should be clear and any complicated or annoying barriers should be stripped down. This isn’t the time to get cheeky with the user. Alternately, if your idea is a trivia game bot, now that’s the time to get cheeky. If users are playing with a trivia bot, they will need less guidance through the instructions because their full focus will be on the game.

Your user

To get started, take a minute to write out a few user scenarios. This doesn’t have to be a formal flow — that will come later — but it will help you get into the mindset of having a user interact with your product. For example, here is what we wrote for our prototype, Mood Mixer. This bot is for:

  • The party hosts that have guacamole all over their hands.
  • Those running late for hosting dinner with their parents.
  • Someone who just got broken up with and has no energy to search for a perfect playlist

All of these scenarios show that a user wants a simple, uncomplicated experience.

Keep ’Em Coming Back For More

Okay, you have an idea and you know who the users will be, but how do you keep them coming back? The key to success is making a low effort, high reward bot that can easily become part of a user’s daily routine. One way to do that is to always be adding more content or providing insider information (ex. HBO’s Westworld Bot).

Write down what would make you come back to the bot after a first interaction. Did you enjoy the ease of making a playlist? Did you have fun playing trivia? Did it improve your day-to-day routine? Figure out a few goals — this will come in handy for the next step.

Creating a Persona for Your Bot

Once you’ve figured out for whom you are designing and how to keep them engaged, it’s time to build a persona based off of those findings. Creating a persona for a bot is a little different from creating user personas, so stick with me.

First, think about the brand associated with this bot (if there is one). For example, if you are creating a bot for Glossier, a makeup and skin care company, it would need to embody the brand or core brand attributes. Like Glossier, the bot would be a little cheeky, helpful, optimistic, and kind. As the creator of this bot, it’s essential that you own the personality. If you don’t, the users will assign their own to the bot and may miss the mark entirely.

Going back to Mood Mixer, this is the persona chart we made:

Mood Mixer’s Persona

We started with the core brand attributes. Since the Mood Mixer isn’t attached to a brand, we thought of words that define the experience of our bot.

Next are the design principles. These relate to the core brand attributes and how they will manifest in design. If a core brand attribute is cheeky, design principles could be trendiness and including easter eggs.

After figuring out the core brand attributes and design principles, finish with the attributes that get included into the voice, style of writing, and personality of the dialog. To continue with the Glossier example, the writing style would include slang and the dialogue personality would be humorous and casual like you are chatting with a very knowledgeable friend.

If you plan on building a bot and having the dialog is be written by someone else, it’s a good idea to create a style guide for your dialog so it stays consistent.

How to Build a Conversation (VUI)

First, let’s think about what a conversation is. A conversation opens a channel between more than one person and sets up a common ground or understanding. Both members in a conversation are committed to engaging with one another. Conversations change over time. If someone does not hear something or misinterprets, the conversation will need to be “repaired”. I’ll explain further in a few paragraphs, don’t worry.

Refer back to these basic principles while writing dialog for the bot. It’s easy to follow similar patterns from GUI, but in a conversation, it’s important to be extra careful to not overload the user with questions. Always remember to end statements with a question or a confirmation. If you start with a question and end on the statement, the user will forget the first question asked or respond before the Google Home has finished speaking.

Be aware of the bot’s vocabulary. Refer back to the persona here to infuse your bot’s personality with the vocabulary choices. There is a difference between “Cool, let’s try a new song.” and “Confirmed, I will play a new song.” Both are acceptable, but they match two different personas.

Now that we have thought about the structure of a conversation, let’s map it out. Start by sketching out all of the options available — they do not need to be fully fleshed out. Something we found to be helpful was to note, in our sketches, both the user’s inputs and the bot’s intents. Then we would assign key actions to them (save input, review intent, etc) and fill in the full conversations later. Below is an image of all of the variables roughly sketched out.

All of the variables sketched out

Next write a “happy path,” a perfect scenario with full dialogue. Below is a screenshot from a Google doc of our first pass at a happy path. In the happy path, we don’t show all of the variables, just one flow that would be most common. This helps us begin to shape the vocabulary and conversation. After the happy path, write the user’s first time experience with the bot. Make sure this includes some type of onboarding. If a user has to set anything up online before being able to use the bot, make note of this as it is all part of the user’s experience.

We started writing our flows in Google Docs

After creating a happy path, it’s time to write repairs. Repairs are used when the bot cannot understand something input by the user. We wrote a global repair that could work in any scenario and then went into more detail of moments when users might need extra explanations or assistance. For example, we wrote repairs for when users are asked to input data about their playlist or whether or not they want to save and name their playlist. We figured these moments might cause confusion and thought a custom repair would help the user work through that request. We also created a “help” repair. If the user needed help with more than just the action at hand, we wrote a response that explains the bot again. This is useful if someone other than the original onboarded user is interacting with the bot or if the original user forgot the action.

Repairs

Now that you have the pieces of your dialogue and flow, let’s put it all together. Below is our full flow for Mood Mixer. It includes all of the variables and exit points the user can reach. User actions are labeled as inputs and bot actions are labeled as intents. We did this to make the transition into AI.api easier for Arnaud and Tim (the developers). Throughout the flow, I highlighted the keywords the user can say that will trigger the bot’s intent. How the user says it can vary, but the keywords are consistent.

Mood Mixer’s full flow, view here

Test and Revise

After all of your variables are added into api.ai, test your bot. This is the best way to revise your copy and flow and test it using the web simulator. Testing lets you try out the whole bot — give it a go and see where the issues lie. If your bot is far enough along, let someone else test it out on the web simulator. The goal of user testing your bot is to figure out how people naturally answer the questions presented. This will allow you to plan for more variables and help you build a well-rounded bot.

Use API.ai’s web simulator to test your bot

TL;DR

Here’s the to-do list for creating a bot:

  • Understand your user and the context they will be in when using your bot
  • Figure out reasons why users should come back
  • Build a persona for your bot based on core brand attributes, design principles, and the voice, style of writing and the personality of the dialog
  • Write a “Happy Path” (Everything goes well for the user)
  • Write a “First Time Experience” (Include onboarding)
  • Figure out conversational repairs (per input and globally)
  • Bring all of these into a flow that shows all the variables and repairs
  • Test with users and revise dialog and inputs
ur new bot

--

--

Liz Wells
Team Stink

User experience designer living in New York City. Currently at Stink Studios. lizvwells.com