Assistant

For clarity, we’ve shown this as a linear process. However, in practice, these are not discrete steps that are fully completed before the next is begun. To borrow software development terms, the conversation design process should be more “agile” and less “waterfall”, with considerable testing and iteration done throughout.

First, determine whether conversation design is the right fit for the Action you want to build.

Next, you’ll focus on your users. Who are they? What are their goals? What’s their context? Considering technical limitations, level of effort, and timeline, what use cases can you support? This is all part of gathering requirements.

Focus on the other half of the conversation. Who’s going to be the voice of your Actions? This is when you get to create a persona that represents your brand and mission.

Now it’s time to start working on high-level designs. If you’re new to conversation design then start by learning about conversation before moving on to writing sample dialogs and diagramming high-level flows. Focus on the spoken conversation first, because if you start designing with a screen in mind, it’s easy to lose the thread of the conversation and end up with a graphical interface that’s not suitable for conversation.

As soon as you have some sample dialogs, start testing and iterating on your designs.

In the last phase of the process, you’ll specify the detailed design. This involves making sure your feature adequately covers the long tail of ways a conversation can deviate from the most common paths. To account for this, you’ll add handling for errors and other unlikely or uncommon scenarios.

Finally, you’ll scale your design to help users wherever they are. Since the Google Assistant helps users across devices (like Google Home, phones, smart displays and more), your Actions should, too. So in this final step, you’ll re-design your spoken conversation as a fully multimodal conversation.

Flowchart of the conversation design process