Creating effective error responses

• No Match Error. These errors occur when the user says something that the system doesn’t understand. This is the most common error when there’s an ASR (Automatic Speech Recognition) error. However, it can also occur if the user is in a noisy environment, their utterance isn’t included in the app’s recognition grammar, or when the user doesn’t respond fully or clearly enough for the system to understand. For example:
  System (hears): “Refrat the camon!”
  System (responds): “Sorry captain, what was that?”
  System (hears): “I said reload the cannon!”
  System (responds): “Aye captain! Cannoneers, reload!”
  Error response: A quick response asking the user to repeat themselves is usually the best way to handle a No Match error. However, if the user’s utterance is already in response to a question, don’t repeat the question. This only serves to sound robotic or break the user’s immersion. Rephrase the response, instead.
• No Input Error. These errors occur when the system expects a response and doesn’t receive one. This can happen for a variety of reasons, such as if the user doesn’t speak loud enough for the microphone or when they don’t say anything when the microphone isn’t active. The user might be thinking about their answer, be unsure about how to respond, or become distracted, or have paused for some other reason. For example:
  System (statement): “You got it, Player 1! Where should we go?”
  System (hears): “...”
  System (responds): “Player 1, which direction shall we go?”
  System (hears): ”Oh, let’s take troops south to D1”
  System (responds): “Got it, south to D1. On our way!”
  Error response: Rephrasing the question with additional detail is usually the best option with this error. As with the No Match error, it’s important not to repeat the question verbatim, so as not to sound robotic.
• Out of Domain Error. This error occurs when the system understands what the user said, but can’t act upon it for some (game-oriented) reason. This is also sometimes known as an Intent error. This can happen because a game rule prevents the requested action from occurring, or because the functionality has not been built into the app. For example:
  System (hears): “Bring me that sword.”
  System (responds): “I wish I could, but I’m actually not able to pick up any weapons.”
  Error response: Wherever possible, you want to guide the user toward a solution, or provide them with information so they can contextualize the response. The most effective response is to explain what the app can’t do, for example, “I’m actually not able to pick up any weapons” so the user doesn’t try it again. However, you should take care that the system’s response doesn’t break the user’s immersion.
• System Error. This is a catch-all category for errors that are out of the user’s or system’s control. These can include client errors, server errors, or virtually any other error that might happen in an unexpected way or in the system backend. For example:
  User (speaks): : “Take me to the starting zone.”
  \<System error>
  System (responds): “Sorry, something weird happened. Try saying that again.”
  Error response: To the extent possible, you should have one or more error responses available that can be used for this type of error. An appropriate response should be as broad as possible to cover as many situations as possible, but not generic enough to sound like a mechanical response. If you have specific information on the error that can be acted upon by the users, such as “Sorry, the internet is not connected,” it can be added to the response, but you should make an effort to prevent it from breaking the user’s immersive experience as much as possible.

• The best error responses are context-specific. Evaluate the context of the scene when creating the error response. Look at the environment, previous questions asked, the user’s position, and other factors. Ask yourself “Would it be weird if a character said this to me?” before applying a given error response.
• Make the error sound like part of the game. If the user is playing an action game, consider creating a visual cue that communicates that the user should repeat themselves if there is a No Match error. When designing NPC dialog, expect the user to pause before responding, so provide them enough time to answer, and have follow-up questions ready for No Input errors.
• Don’t repeat the same response over and over. Users will often repeat what they said, but “carefully.” If it’s a No Match or No Input error, this may work, but for other errors, it might not. There may truly be an ASR or NLU error that prevents the system from understanding. Repeating the same message such as “Sorry, I didn’t get that” will quickly become tiresome to users. Make your app more dynamic for your users by creating variant responses or additional error messages for when the same error is repeated.
• Review your metrics. You can use errors as a signal for ways to improve the user voice experience. For example:
  • Are users asking for things you didn’t anticipate?
  • Where are these errors happening most often? Try and figure out why these errors are happening where they do.
  • Are users asking for things they can do, but in ways you didn’t anticipate? Look at failed utterances to help address future user scenarios.
  • Are people asking for supported features, but the app keeps misunderstanding the requests?