Questions
Wide- to narrow-focus questions
Questions fall on a continuum from wide- to narrow-focus, based on the range of responses they elicit.
When designing a question, think about where it should fall on the continuum from wide to narrow focus. Consider the pros and cons in the table below.
Pros | Cons | |
---|---|---|
Wide-focus question
Best for questions about domains that are familiar to the user and therefore are easy to answer. |
|
|
Narrow-focus question
Best for questions about complex or unfamiliar domains, or when options are limited or unclear. |
|
|
Think about what users could say
Before asking a question, think about what responses you can reasonably support. Don’t ask the user a question if you’re not prepared to handle their answer.
That said, don’t be afraid to ask the user a question—it doesn’t mean that you have to support every response imaginable. The way a question is phrased sets the user’s expectations for what they can say. This phrasing can range from open-ended, or wide-focus questions, to close-ended, or narrow-focus questions.The magic and art of good conversation design is that users feel like they’re in control and that they can say anything at anytime, but in reality, the dialog directs them along pre-scripted paths.
Don’t keep speaking after asking a question
![](https://developers.google.cn/static/assistant/conversation-design/images/turntaking2-do.png?authuser=0000)
Do.
Prompt the user with only a single question at a time.
![](https://developers.google.cn/static/assistant/conversation-design/images/turntaking2-dont.png?authuser=0000)
Don't.
Don’t overwhelm the user with options and questions.
Critical use cases for narrow-focus questions
Error handling
The first time asking a question, your persona should present only the details that are required to proceed.
When there’s an error, narrow the focus of the question to provide more support and get the user back on track.
See errors for details.
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-critical-errorhandling-do.png?authuser=0000)
Do.
Provide extra help when there’s an error.
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-critical-errorhandling-dont.png?authuser=0000)
Don't.
Don’t slow all users down with details that most won’t need to answer the question. Remember, irrelevant speech is time consuming.
Disambiguation
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-critical-disambiguation-do.png?authuser=0000)
Do.
To resolve ambiguity, ask the user a narrow-focus question.
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-critical-disambiguation-dont.png?authuser=0000)
Don't.
The user’s request is ambiguous. This response would’ve been appropriate if the user has ordered pink roses for their mom in the past.
Explicit confirmations
Though they’re uncommon, explicit confirmation questions are necessary in these cases:
- When the cost of misunderstanding the user is high (e.g., names, addresses, text to be shared on the user’s behalf)
- Prior to performing an action that would be difficult to undo (e.g., deleting user data, completing a transaction)
See confirmations for details.
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-critical-explicitconfirmations-do.png?authuser=0000)
Do.
Before deleting user data, use narrow-focus questions to confirm.
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-critical-explicitconfirmations-dont.png?authuser=0000)
Don't.
It would be difficult to recover from an error here.
Learn from what users said
The insights gleaned from user data are invaluable, shedding light on how to better phrase your questions. Analytics and monitoring tools can help you learn how your questions are performing in the wild. Review all the ways users appropriately. Also look for signs of user confusion—for example, perhaps users are not responding (No Input), they take a long time to respond, or they’re hesitant, using filler words like um and ah.
There are 3 main approaches to handling unsupported responses:
- Add new synonyms to the grammar so that they map onto existing functionality
- Restrict the range of responses users can give by narrowing the focus of the question
- Design a new conversational path to support the requested functionality
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-learnfromusers-do.png?authuser=0000)
Do.
Rephrase questions to make the options clear.
![](https://developers.google.cn/static/assistant/conversation-design/images/questions-learnfromusers-dont.png?authuser=0000)
Don't.
Typically, intonation and context will make it clear to the user that this is an either/or question, not a yes/no question. But if users are having trouble, consider rephrasing.