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.
There are 2 types of things that might need to be confirmed:
Key pieces of information that were said or implied
Example: men’s running shoes (shoe style), royal blue and neon green (color)
Something the assistant is about to complete or has completed
Example: Adding a session to the user’s schedule
And there are 3 ways to handle them:
1) Explicit confirmation
Requires a response from the user to confirm (“Did I get the message right?”). Usually yes/no or some synonym.
2) Implicit confirmation
Does not require a response from the user, although users might give one if they want to make a correction (“no, 3 people”). Simply confirms (“for 2 people sitting together”) and moves on. In this example, the next step is to explicitly confirm purchase of these specific seats.
3) No confirmation
No overt confirmation (of the zip code).
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.
Implicit confirmation of actions (common)
Acknowledge that an action has been completed (unless it is self-evident).
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”.
No confirmation of parameters (rare)
Don’t confirm if the input is simple and typically recognized with high confidence, for example, yes/no grammars.
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.
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.
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.
Build dialogs to support corrections.
Let users make changes to any of the parameters (the key pieces of information that were said or implied).