Our recommended design process gives you an easy way to think of use cases, ensuring they sound natural, and serving as a solid developer reference when you build out your conversation action.
The main steps are:
- Pick the right use cases
- Create a persona
- Write dialogs
- Test it out
- Build and iterate
Optimize for conversation: Pick the right use cases
Users make conscious tradeoffs when deciding to use a conversational interface over traditional UIs. Oftentimes they're running out the door, don't have the time to browse a website for information, they need to keep their eyes on something else, or have their hands full.
Don’t be tempted to take an existing mobile or desktop app and "convert it to a conversation". Conversations bring speed and simplicity, but can easily become overly complex when based on another mode of interaction.
Here are some guidelines on what types of use cases transfer well to conversational interactions:
- Things people can answer off the top of their heads. Actions that require familiar input, such as basic user information, locations, times, and dates. Familiar information is easy for users to recite and simple to store, so you can minimize time spent within your action for future uses.
- Quick, but compellingly useful actions. These usually give users a lot of benefit for very little time spent. For example, ordering food in a few seconds and having it appear 30 minutes later or asking for a ride and having a cab at your doorstep in a few minutes. Other convenient actions might involve looking up answers, doing quick calculations, logging or tracking information, or anything that avoids interrupting another task to pull out your phone or find a piece of paper.
- Actions that are inherently better suited for voice. These are typically things you want to do hands-free, like hearing a recipe while cooking or making a mental note while driving. These types of uses cases also translate very well to devices with screens that require hands-on interactions. This is because interacting with screens requires quick taps and gestures that become easier to carry out if the UI is focused on quick, hands-free interactions.
Create a Persona
Before designing your conversational interfaces, think about how you want your conversations to feel and sound. If you're creating a fun game, you might want to use a whimsical tone. If you're creating a news reader, you might want to use a more deliberate, serious tone.
Many people feel foolish or awkward interacting with devices that don’t seem to share their level of conversational experience. And because of the intimate, personal nature of human language, we generally won’t use a conversational UI that offers no clear advantage over other modes of communication. UI design should be tailored to a person’s mental model of the assistant (or any other character taking on the manufactured role in the conversation). User research will lead the way to understanding that model. So we need to design for people, and let the devices follow.
Personas help you design and write your conversations, so choose one early on to make it easier to pick the right words, syntax, and structure. Remember, since users will perceive a persona whether you plan for one or not, it's in your brand's best interest to frame the experience YOU want to be perceived instead of leaving it up to chance.
Picking your voice
The Google Assistant provides different voices to choose from to help you match your persona, which correspond to specific languages and locales. See Languages and Locales for more information on which types of voices you can use.
Now that you have chosen a few use cases and decided on a persona, you might be tempted to dive into development, but refuse the urge!
Instead, start by jotting down the conversation with a pencil and paper, or anything you prefer that gets you writing quickly.
To get started, write down multiple and separate dialogs that users can potentially go through. Here's a few types of dialogs that you should think about writing:
- A "happy path" for users to go down; one that isn't too complicated and accomplishes the action in the easiest way.
- Additional paths users might take to come to the same ending as the "happy path". This might be a variation where some users give information one piece at a time and others speak it all at once.
- Conversation repair scenarios where users do something unexpected, such as asking to do something you don't support or not being able to understand them.
- Dialogs where users exit in the middle of a conversation or at the end of it when they've done what they wanted. Think of how to confirm the end of the conversation.
- Greeting users and how your action is invoked. See Invocation and Discovery for more information on the ways users can invoke your actions and write dialogs that start in different ways.
- Once you have a good idea of how your dialogs sound, think about how the dialogs should appear on devices with screens. Actions on Google provides a variety of screen affordances that let you cater the experience for devices such as phones where both audio and visual UI components can be used. For instance, you might want your TTS to speak back something different than what is displayed on the screen because of the use of images. When your conversation needs it, you might want to create completely different dialogs for devices with screens. This might be useful for times when you need a simplified experience for audio-only devices, such as quickly reordering recent items and a full shopping cart experience on devices with audio and screen outputs.
Test it out
Testing out your app is actually easier than you might think. All you need is someone who wasn't involved in the development. Have them use the app without any hints or clues on what to do. Going through this process a few times should give you some insight as to which conversation paths are hard to get to or how the responses sound in relation to the user's interactions.
Afterwards, get their personal feedback. Where did they get stuck? What felt "off"? This information is a small set of what you'll get from the broader world of users, and you're getting it before publishing your app.
Principles to design by
Keep it short
Respect users' time. Get to the point and get out of the way.
Give them credit
People know the language and they know how to talk, so avoid telling them how to speak and putting words in their mouth. Instead focus on natural ways to progress the dialog forward.
Optimize for relevance
Be contextually relevant and sensitive to the user's current need and the environment a user might be in.
Delight the ear without distracting the mind
When adding personality, be sure it's not so over the top as to interfere with a user's task.
Engage beginners and attract experts
Designing for many people doesn't mean designing for the lowest common denominator.
Don't take back your turn prematurely. If you ask the user a question (yield your turn), don't throw in an additional instruction that gets in the way of their right to answer you.
Don't read minds
Give them the facts and let them decide.