Conversational components Confirmations

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 Expand and collapse content An arrow that points down when collapsed and points up when expanded.

There are 2 types of things that might need to be confirmed:

1) Parameters

Key pieces of information that were said or implied

Example: men’s running shoes (shoe style), royal blue and neon green (color)

Persona: Sekai (fake shoe store). User input: I want the blue and green ones. Spoken prompt: Got it. The men’s running shoes in royal blue and neon green. In what size?

2) Actions

Something the assistant is about to complete or has completed

Example: Adding a session to the user’s schedule

Persona: Google I/O 18. User input: Add that to my schedule. Spoken prompt: Alright. I’ve added it to your schedule. Now, do you want to hear about the other sessions?

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.

Persona: Miso flowers (fake flower shop). User input: Yes. Dear Lola, I hope these flowers make you happy at work. Spoken prompt: Ok, did I get that right? Display prompt: Did I get the message right? Visual: Basic card showing bouquet and message. Chips: Yes. No, try again.

2) Implicit confirmation

Does not require a response from the user, although users might give one if they want to make a correction. Simply confirms (“for 2 people sitting together”) and moves on.

Persona: Ibento (fake ticket-seller). User input: 2. Spoken prompt: Alright, here’s the best open spot for 2 people sitting together. Would you like to get these? Visual: Basic card showing seat location, price, and seating chart. Chips: Buy tickets, VIP seating, Pricing chart.

3) No confirmation

No overt confirmation (of the zip code).

Persona: Miso flowers (fake flower shop). User input: 94043. Spoken prompt: And what’s the street address?

Usage Expand and collapse content An arrow that points down when collapsed and points up when expanded.

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.

Persona: Number Genie. User input: 30. Spoken prompt: It’s higher than 30. What’s your next guess?

Do.

Confirming the number guessed assures the user they were understood, and helps frame their next guess.

Persona: Number Genie. User input: 30. Spoken prompt: I heard “30”. No, that’s not it. It’s higher than that. What’s your next guess?

Don’t.

Don’t belabor confirmations by focusing on what your Action heard or what the user said.

Implicit confirmation of actions (common)

Acknowledge that an action has been completed (unless it is self-evident).

Persona: Ibento (fake ticket-seller). User input: Share that with Diane. Spoken prompt: Ok. I’ve sent the event details to Diane’s phone. Anything else?

Do.

Confirm that the details were sent, and let the user know where they were sent.

Persona: Ibento (fake ticket-seller). User input: Share that with Diane. Spoken prompt: Anything else?

Don’t.

Users may not trust that the details were set.

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”.

Persona: Geek num (fake game). User input: Stop. Spoken prompt: No response. Exit earcon plays.

Do.

By default, your Action leaves the conversation. See app exits.

Persona: Geek num (fake game). User input: Stop. Spoken prompt: But we’re having so much fun. Don’t stop now. What other number can I tell you about?

Don’t.

Your Action cannot force the user to continue the conversation.

No confirmation of parameters (rare)

Don’t confirm if the input is simple and typically recognized with high confidence, for example, yes/no grammars.

Persona: Sekai (fake shoe store). Spoken prompt: Hi, welcome to Sekai. You’re looking for sneakers, is that right? Display prompt: Hi, welcome! You’re looking for sneakers, is that right? New turn. User input: Yes. Spoken prompt: Alright, let me see what I have for you. Display prompt: Alright, let me see what I have for you.

Do.

Note that the user’s ‘yes’ response is not confirmed.

Persona: Sekai (fake shoe store). Spoken prompt: Hi, welcome to Sekai. You’re looking for sneakers, is that right? Display prompt: Hi, welcome! You’re looking for sneakers, is that right? New turn. User input: Yes. Spoken prompt: Ok, yes. Let me see what I have for you. Display prompt: Ok, yes. Let me see what I have for you.

Don’t.

Don’t confirm yes/no grammars, i.e. “Ok, yes.”

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.

Persona: Ibento (fake ticket-seller). User input: Cancel my membership. Spoken prompt: Sure, I can do that. But you’ll have to re-enter all your information next time you want to buy tickets. So, are you sure you want me to cancel your Ibento membership? New turn. User input: No. Spoken prompt: Ok, you’re still a member. Now, did you want to search for tickets?

Do.

Explicitly confirm before deleting user data. (Also, notice that not canceling the membership was implicitly confirmed, so there’s no ambiguity.)

Persona: Ibento (fake ticket-seller). User input: Cancel my membership. Spoken prompt: Ok, I’ve cancelled your Ibento membership. Can I help you with anything else?

Don’t.

It would be difficult to recover from an error here. Creating a new membership account is time consuming and information associated with the account would be lost.

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.

Persona: Miso flowers (fake flower shop). User input: Yes. Dear Lola, I hope these flowers make you happy at work. Spoken prompt: Ok, did I get that right? Display prompt: Did I get the message right? Visual: Basic card showing bouquet and message. Chips: Yes. No, try again.

Do.

Confirm the exact message to be sent prior to sending since the user is unable to correct it after it has been sent.

Persona: Miso flowers (fake flower shop). User input: Yes. Dear Lola, I hope these flowers make you happy at work. Spoken prompt: Lovely. Now, in case we need to reach the person you’re sending this to, what’s the best number? Display prompt: Lovely. Now, what’s the recipient’s phone number in case we need to call during the delivery?

Don’t.

Here, it’s not clear to the user what message will be included. If there was an error, the user would never know unless Lola (the recipient) said something.

Corrections Expand and collapse content An arrow that points down when collapsed and points up when expanded.

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.

Persona: Miso flowers (fake flower shop). User input: Can you add a few pansies as well? Spoken prompt: Alright, I’ve added a few tansies to your bouquet. Will that be all? New turn. User input: No, I said pansies. Spoken prompt: Got it. That’s pansies instead. Do you want to add anything else?

Do.

Allow users to make a one-step correction.

Persona: Miso flowers (fake flower shop). User input: Can you add a few pansies as well? Spoken prompt: Alright, I’ve added a few tansies to your bouquet. Will that be all? New turn. User input: No, I said pansies. Spoken prompt: Alright, what else do you want to add?

Don’t.

Here the user’s response was misinterpreted as a “no” to the question “Will that be all?”

Build dialogs to support corrections.

Let users make changes to any of the parameters (the key pieces of information that were said or implied).

Persona: Miso flowers (fake flower shop). Spoken prompt: Okay, I’ve got 1 custom bouquet with 4 white peonies, 3 pink carnations, 3 yellow tansies, and 4 yellow roses. Do you want to add that to your cart? New turn. User input: No. Spoken prompt: What do you want to change? New turn. User input: The tansies. Spoken prompt: Alright. What flower do you want instead? New turn. User input: Pansies. Spoken prompt: Got it. So that’s 1 custom bouquet with 4 white peonies, 3 pink carnations, 3 yellow pansies, and 4 yellow roses. Should I add that to your cart?

Do.

Disambiguate what users want to correct and ask for the new information.

Persona: Miso flowers (fake flower shop). Spoken prompt: Okay, I’ve got 1 custom bouquet with 4 white peonies, 3 pink carnations, 3 yellow tansies, and 4 yellow roses. Do you want to add that to your cart? New turn. User input: No. Spoken prompt: Alright. Do you want to browse our bouquets, or create a new bouquet?

Don’t.

Don’t cancel and force users to start the dialog over, in this case by creating a new custom bouquet.