You Can Say That Again: The Role of Repetition in Conversation Design
By: James Giangola
Tags: Conversation Design, Language, Ux Writing, Repetition, UX

Just as repetition plays a useful role in natural, everyday conversations, it’s also a valuable but often overlooked technique in conversation design. To get to the heart of why repetition is so important in conversation design, we first have to understand the problem of “false accepts” in speech recognition technology.

To begin with, a “correct accept” is when the user says something and the recognizer gets it right. In contrast, a false accept happens when the user says something, and the recognizer gets it wrong. For instance, the user has said “Round-trip ticket to Austin,” but the recognizer wrongly parsed the utterance as “Round-trip ticket to Boston.” Other examples of false accepts would be “June thirteenth” misrecognized as “June thirtieth” …or “forty dollars” misrecognized as “fourteen dollars.”

As speech recognition systems are becoming more and more accurate, false accepts are becoming less common. (Even so, it’s critical to design for them, for reasons we shall soon see.) Perhaps someday they’ll become a thing of the past, but for the meantime, since we don’t yet have “perfect” (well, as-good-as-human) speech recognition, how can we at least minimize the problem? Enter repetition!

Here’s an example of a mini dialog without the recognizer repeating what it “thinks” it heard:

User: What’s 11 times 3?

Assistant: The answer is 21.

This response is confusing, because most of us know that the answer isn’t 21. The design of this message makes it look like the Assistant can’t do basic arithmetic. And, if this were a more complicated math problem, we might just accept the answer as correct and be done with it.

Now here’s how the dialog would proceed if the recognizer were to repeat to the user what it “thought” it heard:

User: What’s 11 times 3?

Assistant: 7 times 3 is 21.

User: No, what’s 11 times 3?

Assistant: 11 times 3 is 33.

By repeating what we think the user said, it’s clear right off the bat that there was actually a speech recognition error — a false accept. By making the system’s “recognition hypothesis” transparent to the user, the assistant no longer appears to be bad at arithmetic (maybe just a little hard of hearing on occasion). And then the user knows to ask again.

When we repeat a key piece of information from the user’s request, that’s called “implicit confirmation.” This sort of repetition is useful in conversation design so that users know whether or not they’ve been understood correctly by the system. On one hand, when the recognizer gets it right, implicit confirmations offer reassurance. This reassurance gives users confidence in the recognition technology, especially if they’ve been burned by bad experiences with other, less accurate systems in the past. On the other hand, when the recognizer gets it wrong, implicit confirmations let the user know that they need to try again or to refine their request. That makes the design “forgiving.” That is, when mistakes happen, the design minimizes the consequences of the error.

Here are some more examples of implicit confirmations:

User: What’s the state motto of Georgia?

Assistant: Georgia’s motto is “Wisdom, Justice, Moderation.”

User: Who is the Prime Minister of India?

Assistant: The Prime Minister of India is Narendra Modi.

User: Call Amber Gómez.

Assistant: Calling Amber Gómez.

Especially if the user has no access to a screen — let’s say they’re driving — then hearing “Amber Gómez” lets them know they’re about to be connected to the right person. After all, think of the tongue-tying, reddening chagrin we feel when we realize we’re now conversing with the wrong contact. This reminds me of the store owner who inadvertently sent me a heartfelt text message apologizing for “the fight last night” — the one we never had — and hoping that I had calmed down. Oops, wrong contact! (And yes, I did respond.)

Of course, implicit confirmations don’t necessarily depend on verbatim word repetition. It’s also possible to substitute with a synonym or paraphrase:

User: Set an alarm for tomorrow morning at 5:30.

Assistant: Okay, 5:30 AM. Your alarm’s set.

…where “AM” is synonymous with “in the morning.”

There are some assistive situations in which implicit confirmation is unnecessary. For example, if you ask your digital assistant to turn on the flashlight, the light should go on — no confirmation needed. Seeing the light turn on is a confirmation in itself, so hearing “Your flashlight is on” (an implicit confirmation) doesn’t add any value. (Perhaps the assistant can simply acknowledge the request with an acknowledgement, such as “Alright” or “Okay.”) On the other hand, if the user is sitting in their living room and asked their assistant to turn the lights off in the bedroom, then an implicit confirmation would indeed be necessary so that the user knows what happened and where (“Okay, turning the lights off in the bedroom”).

Another consideration is whether or not the user will need to look at a screen. For example, if the user asks to see a map of San Francisco, an implicit confirmation of the location isn’t critical because the user is going to look at the screen anyway and then see what the system understood. On the other hand, if the user asks for the weather in San Francisco, we can’t assume that they’ll refer to the screen, so implicitly confirming their request is a good idea.