Handling errors and ambiguity

No matter how clear your messages are, a user may still misunderstand, become confused, or encounter an application/system error. When designing your application, you need to communicate clearly, keep the user engaged, avoid ambiguities, and detect and recover from errors.

Error handling

Your role is to guide your users: give them just enough information to keep them moving toward their goal, in as natural a way as possible. Anticipate errors and gently lead users by reinforcing information and by escalating instructions and feedback as required.

Common failure conditions include recognition/find-meaning failures:

• Nomatch events. For example, when the user’s utterance is not recognized. This event may occur due to limitations in the NLU model, which indicate that retraining may be required, or due to background noise such as the user coughing or a dog barking.

• Noinput events. For example, when the user remained silent or the system was simply unable to detect an utterance.

Create special handling for these types of events: consider how many times your app should prompt the user when the failure occurs and what types of messages to use.

For example, for a second noinput result, you might use “Sorry, what was that?” and on the third noinput (user continues to remain silent), provide more detailed instructions or provide examples in case the user is uncertain what to do or say next, such as “Here are some things you can say…” Another option is to suggest that the user try a different action, such as “Sorry, you can try one of these…” As a final fallback strategy use a yes/no question to move the dialog along, such as “Do you still want to place an order? (Just say ‘Yes’ or ‘No’.)”

If many noinput timeouts are observed for a dialog state, consider refining the language. A message may be misleading, incorrect, or insufficient for the user to act on.

Failure scenarios don’t have to be negative experiences—instead, reinforce information about what is expected of the user at that point in the dialog flow and the available options. When appropriate, provide examples. Users pattern their responses on examples.

For system errors, provide a description of the error and suggestions as to how to recover. A recovery suggestion is preferable to cryptic error message and “Please try again”.

Ambiguity

You have a certain degree of control over what your users will say or do. Users will react to the views to which they have navigated and to the buttons they see displayed in your application’s interface. Their reactions are also influenced by their past experiences and expectations when dealing with your business.

Sometimes, however, a user’s request is too vague or general and a single interpretation cannot be made (meaning cannot be determined). In these cases, the application must prompt the user to fill in the missing information. For example, you might:

• Provide examples
• List and/or aggregate options
• Rely on the multimodal experience to enable all input methods including touch selection, if applicable
• Reduce the information to collect; for example, at the application design level by setting default values or by tracking user behavior

When multiple, non-conclusive interpretations are identified and/or the user rejects the application’s response, you might use the interpretation results returned to use the confidence score to narrow down choices. Typically, applications are most interested in results with the highest score. However, you can use confidence scores to determine whether:

• Confirmation is required from the user; for example, when confidence is low, to require explicit confirmation (“You want to view your list of favorite beverages, is that correct?”)

• A list of possible interpretations should be presented to the user based on highest confidence score (for example, the top three), from which the user can then make a selection.