Gather requirements
Gathering requirements for a conversational experience is not just about defining features and functionality, though that is the main outcome. At its core, the requirements-gathering process is about understanding users and technical capabilities.
Starting with clear, well-researched requirements is the best way to avoid the need for major changes after design and/or development is completed.
Identify your users
Gathering requirements is all about asking questions and using data to answer them. For example:
- Who are your users?
- What are their needs?
- How are they completing these tasks today?
- What words and phrases do they use to talk about these tasks?
- What situations or circumstances trigger these tasks?
Accommodate all users
While it’s important to optimize for your most frequent users, don’t do so at the expense of other users’ experiences. A well-designed product is inclusive and universally accessible. Designing for different populations means leveraging inclusive design or universal design strategies. Often, the accommodation you’re forced to make for one population ends up benefiting everyone (e.g., a ramp is easier than stairs). For more information, see the Material Design guidelines for Accessibility.
Create user personas and journeys | ||
---|---|---|
User persona |
Who is the user? |
A user persona is a specific but brief description of an individual user. Think about the types of people you expect to use your Actions, and create a few user personas to represent them. These user personas will help you avoid designing only for yourself and your goals. |
User journeys |
What are the user’s goals? What’s the user’s context? |
A user journey is the pathway for the user to complete a goal in a given context. |
Critical user journeys |
Describe each of the relevant moments in the journey |
Critical user journeys are those that either 1) happen very often or 2) are of key importance to the user. Aim to help users to complete one of these journeys from start to finish. Focusing on these will help you build Actions that reach a large and/or dedicated audience. |
Example from the Google I/O 18 Action
Who is the user?
![](https://developers.google.cn/static/assistant/conversation-design/images/example-googleio18-action-1.jpg?authuser=0000)
What are the user’s goals?
![](https://developers.google.cn/static/assistant/conversation-design/images/example-googleio18-action-2.jpg?authuser=0000)
What’s the user’s context?
![](https://developers.google.cn/static/assistant/conversation-design/images/example-googleio18-action-3.jpg?authuser=0000)
Describe each of the relevant moments in the journey.
![](https://developers.google.cn/static/assistant/conversation-design/images/example-googleio18-action-4.jpg?authuser=0000)
Identify technical capabilities
Systems
What are the capabilities and limitations of the various systems that your Actions will rely on?
Example: Google I/O 18 allows users to create a personalized schedule of all the sessions they want to attend |
---|
|
Data
What’s the format and quality of any data you’ll be using?
Example: Google I/O 18 reads information about the sessions |
---|
|
Often, some reformatting needs to happen before some types of content can be appropriately rendered in text-to-speech (TTS).
Identify your key use cases
Aim for impact.
What are users asking for?
Example from the Google I/O 18 Action:
If you haven’t already, be sure to read these blog posts for a deep dive on how we designed and built the I/O 18 Action (or take a look at the code).
For the Google I/O 18 Action, we talked with Googlers who’ve worked at the event in previous years. We asked them what kinds of questions attendees usually have during the event. These questions typically fell within one of these 4 categories:
General navigation | Personal navigation | Event details | Location-specific event details |
---|---|---|---|
“Where’s the bathroom?” “Where are the codelabs?” |
“Where’s my next session?” “Where can I get my app reviewed?” |
“What time is lunch?” “When’s the after party?” |
“What’s the next session in this room?” “What can I do here?” |
With that knowledge, we decided to focus on these key use cases:
- Provide wayfinding information for locations specific to Shoreline Amphitheatre, for example: bathrooms, parking, driving directions
- Provide wayfinding information for locations specific to Google I/O, for example: badge pickup, sandbox, codelabs, office hours and app reviews, after hours, I/O store
- Provide event details for all keynotes, sessions, office hours, and meals; allow them to be filtered by time, location, or the user’s schedule