Our recommended design process gives you an easy way to think of uses cases, ensures they sound natural, and serves 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 voice: Pick the right use cases
Users make conscious tradeoffs when deciding to use a voice interface over traditional UIs. Oftentimes they're running out the door, don't have the time to browse a website for information, need to keep their eyes on something else, or have their hands full. Sometimes it just feels easier because it has the fewest steps or they don’t feel like pulling out their phone.
Don’t be tempted to take an existing visual-based app or GUI and simply “convert it to voice”. Voice brings with it speed, simplicity, and hands-free experiences that become overly complicated easily when based on another mode of interaction.
Here are some guidelines on what types of use cases transfer well to voice 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. Information users already know are easy for them to come up with when asked and easy 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.
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 talking to voice-enabled devices that don’t seem to share their level of conversational experience. And because of the intimate, personal nature of a voice, we generally won’t use a VUI that offers no clear advantage over other modes of communication. VUI design should be tailored to a person’s mental model of the voice 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 YOU want to be perceived instead of leaving it up to chance.
Picking your voice
|Male 1||Business, News, Entertainment, Food and Drink||
|Male 2||Food and Drink, Education, Movies, Games (Quiz Show Host)||
|Female 1||Transportation, News, Education, Games||
|Female 2||News, Entertainment, Business, Food and Drink||
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.
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. Avoid telling them how to speak and putting words in their mouth of what to say, but 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.