A fundamental challenge for the user interface designer is knowing when someone is having a problem. But a good start to avoiding problems in the first place is to let people know the system is listening. The designer has two tools to help with this: confirmations and acknowledgments.
Confirmation is how the UI checks in with people to let them know a question, command, or response was understood correctly. Acknowledgements are words or phrases (such as OK or Alright) that show the UI is engaged.
Why confirmation strategies are needed
Confirmations improve the conversational experience by instilling confidence in users. If you don't have a confirmation strategy in place, you run the risk of their input being misinterpreted, and taking them down the wrong path. For example, a person that asks, "What's the weather in Oakland?" and instead gets the forecast for Auckland, New Zealand.
The severity of the risk depends on the context—buying 1,000 shares of the wrong stock, or simply getting the wrong weather report. A savvy UI designer knows which strategy would be most appropriate in a given context to confirm recognition and prevent a journey down the wrong path.
Usually, it's a choice between confirming implicitly or explicitly.
Strategy #1: Explicit confirmation
With explicit confirmation, the UI yields to the user, asking for a verbal agreement before moving on. Two examples:
|That was ____, right?|
|Okay, to confirm, I got ___. Is that right?|
When several items are conceptually related to a transaction, they can often be confirmed together:
|Okay, that's a table for 6 at Quartino, on Friday at 7. Is that right?|
Explicit confirmation is appropriate when the UI is on a path toward taking some action that's difficult or impossible to undo; when a business rule or law requires explicit verbal agreement from the consumer (before finalizing a money transfer, for example); or when system performance is poor.
Strategy #2: Implicit confirmation
With implicit confirmation, the UI incorporates a critical component of the user's statement into its response, so that it's clear what was understood. Here's an example:
|User||What's the state flower of Nebraska?|
|UI||The state flower of Nebraska is goldenrod.|
The confirmation is implicit because the person immediately knows what the system has recognized, since the UI has repeated or paraphrased a critical element.
The repeated element needn't be so precise. Consider this example:
|User||What kind of news can I listen to?|
|UI||In addition to general news, you can ask for almost any news topic, such as technology or sports news.|
The unspoken benefit of the doubt is given to the user for "general" news, thereby avoiding the obvious, which the user has likely already tried and may simply be asking in order to hone their query or test the available features.
Implicit confirmations are appropriate when confidence in accuracy is medium to high, and when potential for a bad outcome is low. The advantage is speed. The disadvantage is that people often don't know how to get the dialog back on track. Keep those factors in mind and choose your strategy to suit the context.
Don't send users back
Many UIs follow implicit confirmation with a quick "Go back" instruction. ("If that's not right, say 'Go back.'") We don't recommend this approach. Instead, construct your recognition grammar to accommodate people's cooperative attempts to get the dialog back on track (see Be Cooperative...Like Your Users). Or, if an "out" is truly needed, confirm explicitly.
Finally, sometimes no confirmation is needed. If you ask to turn on the flashlight, for example, the light should just come on. If results are immediately perceptible, a just-do-it approach works best.
When deciding when to confirm and what type of strategy to use, consider factors such as accuracy and the cost to the person (in money, time, or aggravation) of a recognition error.
Acknowledgers are words and phrases such as Okay, Sure, Thanks, and Got it, which reassure people that they've been heard and lend fluidity and naturalness to the dialog.
- Use acknowledgers to signal acceptance, refusal, confirmation, correction, and before changing the subject
- Be wary of repetition, and don't overuse acknowledgers
A truly conversational UI promotes a natural flow of turn-taking. It communicates that the persona is attentive to the speaker and awaits further dialog as needed. Simple acknowledgers indicate acceptance of the previous turn, and are critical to the success and progress of a conversation. They show that the persona is keeping track of the conversation, which in turn reflects favorably on the product, service, brand, or company values.
Without acknowledgement, people wonder whether the persona has heard them at all. The UI can eliminate this distraction by casually acknowledging the person's contribution before moving on ("Sure. For what time?"). It also opens opportunities to better thread the rest of the dialog together into a cohesive conversation, employing other techniques such as discourse markers (Next, And, So, and Actually).
Take the two examples below. Both gather the same information, but the second uses a combination of confirmation strategies and acknowledgers:
|User Put an appointment on my calendar
UI What's the date?
UI What's the time?
User 2 o'clock
UI What's the subject?
User Sascha's party
UI Sascha's party. Saturday, September 10th, at 2 p.m. is saved.
|User Put an appointment on my calendar
UI Sure. When for?
User Saturday at 2.
UI OK, Saturday at 2 p.m. What should I call this?
User Sascha's party
UI Got it. Sascha's party is all set.
Acknowledgers should be appropriate to the context, brand, type of task, and other details of the dialog (such as whether the person is moving down an error-free path or having problems being understood).
In real-life conversation, we might hear acknowledgers like "Alrighty then," or "You got it!" or even "Doh!" But only use these if they match the rest of your UI—if it's part of the persona you've crafted to deliver that experience, for instance.
Use acknowledgers judiciously and with restraint, so every sentence doesn't start with one. When dialogs are planned or laid out as sample dialogs ahead of time (see our recommended design process ), it's easy to see the flow and the number of acknowledgers used during an interaction.
Explicit repetition of a person's request—"Turn off my mic." "The mic's off now."— is also a form of acknowledgement, and reassures listeners they've been heard. But you can still use acknowledgers to lend fluidity and naturalness.
One way of avoiding monotony and gimmickry is randomization. Not only does it acknowledge that the person has been heard, it confirms that the request has been fulfilled.
To keep things fresh and varied, you can even apply randomization to a particular acknowledger—Done, Okay, Alright, Sure, etc. And we know from the recording studio that voice actors can get very creative, too. Even limiting them to a single word presents little challenge for producing multiple variations based on tone.
Confirm and acknowledge your way to a seamless conversation
Of all the resources in the UI toolkit, confirmations and acknowledgements are among the most critical. They help thread what would otherwise be a disconnected series of impersonal back-and-forth exchanges into a natural conversation. They leverage context, lend pacing and fluidity to the flow, improve comprehension, and generally instil confidence in the user—not only in the current interaction, but in the technology overall.