Following Through on the Initial Design Phase
After the initial phases of the design process have been completed, the designer needs to follow through by asking two fundamental questions.
Where We've Been ”Where We're Going
We've begun to explore the underpinnings of the design process, two ways to express the design ”both textually in a script used to
Chapter Six. Writing Effective Prompts
The difference between an adequate speech-recognition system and a great speech-recognition system lies in how the system asks questions and conveys complex information. Great systems do it with an
This chapter does not discuss topics such as "the
way to ask a 'yes/no' question." Why not? Because, for one thing, there
no single "best way." Rather, there are many different ways to properly ask a "yes/no" question, depending on the situation. I've avoided absolute rules ”and words like "always," "never," "best," and "worst" ”because the state of the art of design is constantly changing. Any absolute rules I could offer would soon be
The Language of Asking Questions
At its most basic level, the design of speech-recognition system prompts is
The questions that are asked need to be clear and not easily misinterpreted, and the statements need to provide useful information, in a
In real life, real people do lots of error checking and correcting. And when we're asked to clarify something we've said, what do we do? We usually rephrase it or provide further information. If the people to whom we're talking need further
Speech-recognition systems need to emulate this behavior, because ”just as in real conversations ”mistakes and misunderstandings do occur. Think of all the things that could possibly go wrong when a system asks a caller a question.
To handle all of these possible situations, speech-recognition systems often use these six types of prompts:
Let's take a close look at each of these prompt types by going through the types of prompts that make up a typical call flow.
When a system enters in a particular state it may provide some information, but then, almost always, it asks a question such as "When do you plan to
If the recognizer hears something, but can't match the caller's utterance with the command vocabulary it is using in that context, then it will play a retry prompt . For example, if a caller says, "Uh, I guess I'm not sure" when the system is expecting to hear a date, such as "April 24th," the system would most likely not understand the utterance and then play a retry prompt to aid the caller.
We often use a retry prompt to clarify an idea with the caller, in the hope that by giving the caller another attempt he or she will understand how to answer a question correctly. For example, after hearing "Uh, I'd like to arrive on the last Saturday in April," an appropriate retry prompt might be an explicit statement, "I'm sorry I didn't understand. Please say the date you'd like to arrive. For example, you could say 'January 29th' or 'February 2nd.' Or for more information, say 'Help.'"
This retry prompt would help many
Currently most speech-recognition engines are designed to reject a response after they've calculated that the caller's response is likely invalid. For example, if the caller
The system needs to determine whether the caller responded. If the recognizer doesn't hear anything, it will usually ask another question providing more information to the caller to elicit a response. This is called a timeout prompt .
To design timeout prompts we always need to ask
So, for example, if a system asked, "When do you plan to arrive?" and fails to hear a response at all, it can provide a timeout prompt, such as "I'm sorry, I didn't hear you. Say the date that you plan to arrive, or for more information say 'Help.'" This new prompt provides a little more information about how to answer the question by instructing the person to say a date (rather than a relative time marker such as "After I get to Portland") and steers them to say "Help" if they need to find out more information about this question.
If callers' responses aren't heard twice in a state, a second timeout prompt can be used ”often to instruct them on how to use touchtones or how to talk to a representative.
Not to be
Here are a few answers to that question.
We need to write our help prompt to address all of these possible needs.
is played when a caller has successfully exited the current state and is entering the
A failure prompt is played when callers have tried ”and failed ”to answer a question several times. They're obviously stuck and need to be either transferred to a "live" representative in a call center, or re-oriented (perhaps by being returned to the main menu). A typical failure prompt goes something like this: "Sorry, but it seems we're having problems. Let me transfer you to someone who'll be able to help. Hold on." In the case of a client without a call center behind the application, it might say "It looks like were having problems. Let's just take things from the top," then proceed to the main menu.
Often the designer can define this prompt once in the Design Specification and simply call for its use whenever a caller fails at a state. However, the designer should always look for situations in which this prompt may be inappropriate ”or inadequate. For example, if the system has already collected information from the caller and can pass it along to a customer service representative, an appropriate prompt might be "Sorry, but it seems we're having problems. Let me transfer you to someone who'll be able to help and I'll pass along the information I've collected so far. Hold on."