7.3 High-Level Design

It is now time to roll up our sleeves and dig into the design of the application. However, we want to start at a high level before drilling down into the details. The goal is to create a framework for the detailed dialog design that is based on the requirements. We also want to make some design choices up-front so that we can apply them consistently throughout the application.

7.3.1 Key Design Criteria

To come up with key design criteria, we review what we have learned about the users and about the business. The target customers want convenience, flexibility to do the things they normally would need a broker to do, efficiency, and the knowledge that any information they receive or transactions they perform are accurate. The business wants to automate calls and provide a system that is easy and satisfying for their customers to use. The key design criteria are as follows: simplicity, accuracy, efficiency, and flexibility. We will refer to these design guidelines as we make design decisions.

7.3.2 Dialog Strategy and Grammar Type

At this point, we can start to determine which high-level dialog strategies we should use in order to meet the guidelines and requirements we have defined. Given the priority of efficiency and the expectation that many users will call frequently, we want to make sure that experienced callers can rapidly and flexibly state their requests. We decide on a mixed-initiative dialog structure, allowing experienced callers to access system functionality directly from the main menu and make complex requests (e.g., "Buy one hundred shares of Cisco at the market").

Allowing the caller to control the initiative at the beginning of the conversation is not without its drawbacks. An extremely open-ended prompt caters to expert users. Novice users will need more guidance. We decide to track callers across sessions via their account numbers. On the first call into the system, we provide the instruction needed for the novice user, meeting our goal of simplicity. Then, after callers have become familiar with the system, we will put the initiative into their hands (promoting efficiency and flexibility). Whenever callers experience difficulties, we will back off to a more directed dialog. If callers remain silent, we will offer additional instruction to remind them what they can do. In this way, the initiative shifts between the caller and the system depending on how smoothly things are advancing.

One impact of this design decision is that we will use a statistical language model, as well as rule-based grammars in modules that perform more constrained tasks.

7.3.3 Pervasive Dialog Elements

At this point we make a few other high-level design decisions related to universals, error recovery, confirmation strategies (making sure recognition is correct), and login strategy. With regard to universals, we will incorporate the six standard ones: help, operator, repeat, main menu, go back, and good-bye. We add one more universal: At any time, the user can ask to speak to a broker. This helps ensure that we will not lose callers, especially if they want to make a trade but are not yet willing to do so with the automated system. We will make sure to remind callers of the availability of brokers in some of the help and error messages.

Next, we define our error recovery strategy. At the initial, open-ended prompt, if we do not hear a response within a few seconds, we will explicitly list the choices available. Similarly, for other errors that occur in the main menu state, we will respond by listing some general commands that the caller can say; these commands correspond to the major functional capabilities of the application. Once the caller is in a more constrained interaction (e.g., the system has just asked "How many shares do you want to buy?"), a rapid reprompt will be used (e.g., a quick prompt such as "I'm sorry?") at the first error, followed by more detailed error prompting on subsequent errors. Additionally, error and help prompts will let a caller know how to return to the main menu and, at select times, how to connect directly to a broker.

The application will also have several mechanisms for helping those callers who are experiencing multiple errors and are at risk of failing to complete their task. We prefer to send these callers to someone who can help them rather than allow them to become frustrated and hang up. We will remind them about the ability to transfer to a representative if they are having trouble entering account numbers or PINs. In addition, on the third error in any given dialog state, we will ask callers if they want to transfer. In addition to dialog state error limits, we will count the number of times the caller negatively confirms information (for example, when placing a trade). If the caller states three times that the information is incorrect, the system will offer to transfer to a broker.

Confirmation will be an important element in the application because we want to ensure accuracy without slowing down the dialog. Trades, of course, will need to be explicitly confirmed, as will other transactions such as canceling an order. However, when the caller is simply receiving information such as a stock quote, the system will offer only implicit confirmation (e.g., "Apple is selling at …").

Another pervasive dialog element is login. There are two approaches to consider: (1) to require login at the beginning of the application for all users, even those who want only to get stock quotes, or (2) to log in users only when they reach a secure area of the application that requires account information, such as placing a trade. This design decision needs to be made before any detailed work begins because the context is quite different between the two scenarios, resulting in different call flows and different prompting. We decide on the first option: logging users in up-front. This will allow us to adjust the prompting depending on the callers' usage patterns. The approach will meet the design criteria of simplicity for novice users and efficiency for expert users.

7.3.4 Recurring Terminology

We want to be sure that there is a seamless coordination of information between the Web site and this system, so we use the general components of the Web site as a starting point for the main components of the speech system. The functional areas include quotes, trading, portfolio, and account information. These will become terms callers can use to navigate to the different areas of the application. In this way, callers will be able to take the mental model they have developed for the Web site and generalize it to the speech system using consistent terminology.

In addition to the main functional areas, we create a list of terms to promote consistency. For example, we decide to call the list of stocks maintained by the caller a "personal watch list." By establishing these phrases up-front, we reduce the risk of introducing inconsistencies in the detailed design.

7.3.5 Metaphor

We begin thinking about the metaphor by considering the style and character of the application. First, we define the service. It is a resource for customers of a brokerage firm that provides up-to-the-minute information and the ability to perform transactions from callers' personal accounts. The relationship between the caller and the service is similar to that of a trader interacting with a broker. In fact, if we recall from the focus group, services like these are beginning to replace interactions with brokers for some customers. Considering this, we choose the overarching metaphor to be a conversation with a live stockbroker.

In choosing this metaphor, we do not want to fool the caller into thinking that the system is a live person. We want only to take advantage of the caller's existing mental model of how to interact with a broker. For example, we would like to assume that the caller has a model of what information to provide in order to place a trade.

7.3.6 Persona

Next, we design the system persona. We think about what this stockbroker should be like. The persona needs to embody the service and also appeal to users, so we must take many elements into consideration. To help us, we use the persona-design checklist from Chapter 6.

Metaphor and Role

The persona should convey the essence of a professional broker.

Brand and Image

We want the persona to reflect the corporate image of the business: knowledgeable, dependable, helpful.

End Users

• Target audience: We decide we want the persona to sound about the same age as most customers (mid-30s) and reflect the language use of an individual of that age with a middle to high income.

• Frequency of system use: Typically, customers will be talking to the system repeatedly, so we want to make sure that the personality is engaging and retains its appeal over time.

• Mind-set of the user: The mind-set of the caller will be on managing money quickly and accurately. Creating a chatty or extremely laid-back persona would be a misguided design decision given what we know about the people interacting with the service. The persona should be quick, to the point, and helpful.

Application

• Content: In the application, callers will be asking for information about stocks, making financial transactions, and managing their accounts. The persona should convey an individual who is knowledgeable about the stock market as well as professional and capable. We need to inspire confidence that the information callers are receiving is accurate and that the transactions are in good hands.

• Task-related issues: Because callers may be asking for numerous stock quotes in a row, we must be sure that the persona is efficient but clear. However, he or she must be ready to slow down and give careful instruction if the caller is having a problem.

Based on these guidelines, we create the persona definition shown next.

Frank Delano

Frank Delano is an ambitious, 35-year-old New York stockbroker. Raised on Long Island, he became interested in the market in high school. He likes investing and learning about new markets. After majoring in business at Fordham University, he joined a prestigious brokerage house, where he now specializes in Internet and technology stocks. When not working, Frank is a mountain biker and skier.

Characteristics:

Knowledgeable (an expert in the field)

Capable (smart, competent, and accurate)

Dependable (follows through)

Helpful (patient, not abrupt; offers help but does not give advice)

Honest (credible and trustworthy)

Efficient (works quickly but is not curt; keeps the conversation moving)

Energetic (very positive and determined)

Vocal Attributes:

No detectable regional accent

Diction is precise and professional but at ease

Pace is slightly quicker than average, although he slows down to give instructions or help the caller who is encountering problems

Linguistic Attributes:

Standard American English

Vocabulary is simple without too much technical jargon

Uses abbreviated phrases instead of complete sentences where appropriate

The character traits in the persona definition are well aligned with the image the business wants to convey. They also embody the type of broker whom customers want to interact with: someone who will provide them with accurate information and is capable of executing transactions efficiently and without error.

We present the persona definition to our client. Because the persona influences many aspects of the design, we want to make sure that the business accepts it before we move forward. Lexington Brokerage is happy with the profile. The executives admit that they have never gone through the persona design process and are excited to see how the speech application will be different from the look and feel of their touchtone system. We will begin the process of selecting a voice actor right away. Although that is part of the production phase, it is a good idea to start early. Chapter 17 describes in detail the process for selecting voice actors.

7.3.7 Nonverbal Audio

Given that our metaphor is a trader having a conversation with a stockbroker, we decide to create a sparse audio environment that consists mostly of the stockbroker's voice. For design elements such as landmarks and latency, we will use language to communicate to the caller what is happening in the application. We will, however, use Lexington Brokerage's branding sound at the very beginning of the interaction (just before the welcome prompt). This is the same sound that appears in the current touchtone system.