Confirmations
Confirmations give users feedback on how their input was understood. This not only empowers users to correct mistakes immediately, but it also reassures them in a socially and conversationally appropriate way by establishing common ground. Furthermore, confirmations help carry the thread of the conversation forward by maintaining context.
What and how to confirm
There are 2 types of things that might need to be confirmed:
Parameters
Key pieces of information that were said or implied.
Example: men's running shoes (shoe style), royal blue and neon green (color)
Actions
Something the Assistant is about to complete or has completed.
Example: Adding a session to the user's schedule
Explicit confirmation
Implicit confirmation
No confirmation
Usage
Some types of confirmations are far more frequent than others. Here’s a list of how to use confirmations, from the most- to the least-common scenarios:
Implicit confirmation of parameters (common)
Use most of the time, not to confirm the user’s input per se, but to confirm the parameters that were said or implied. Users require this context to understand the response.
Do.
Don't.
Implicit confirmation of actions (common)
Acknowledge that an action has been completed (unless it is self-evident).
Do.
Don't.
No confirmation of actions (uncommon)
Use when the action/response itself makes it instantly clear that you understood the user. This is true for global commands like “stop” or “cancel”.
Do.
Don't.
No confirmation of parameters (rare)
Don’t confirm if the input is simple and typically recognized with high confidence, for example, yes/no grammars.
Do.
Don't.
Explicit confirmation of actions (rare)
Double-check with the user prior to performing an action that would be difficult to undo, for example, deleting user data, completing a transaction, etc.
Do.
Don't.
Explicit confirmation of parameters (rare)
Use sparingly, only when the cost of misunderstanding the user is high, for example, names, addresses, texts to be shared on the user’s behalf.
Do.
Don't.
Corrections
Expect users to make corrections, after explicit and implicit confirmations, when there’s been a misunderstanding or misinterpretation of their input. Give users the opportunity to make changes, even when there weren’t mistakes.
Allow one-step corrections.
Expect user corrections to follow the Cooperative Principle by saying “no”, followed by their correction (for example, “No, 7 AM”). This is called a one-step correction.
Do.
Don't.
Build dialogs to support connections.
Let users make changes to any of the parameters (the key pieces of information that were said or implied).
Do.
Don't.