How Do I Change My Mind?:
Designing Multi-Parameter Dialogs that Allow the Changing of Parameters

Wayne Hank & Deborah Dahl

Natural Language Understanding
Unisys Corporation
wah1@trpo4.tr.unisys.com

CHI '97 Workshop: Speech User Interface Design Challenges

Short Biography

Wayne Hank. As part of the Natural Language Understanding group at Unisys, I have designed or reviewed the design of several speech-based applications. These include voice mail, mortgage quote, home insurance quote, airline reservations, and retail banking applications. In addition to designing applications, I have managed speech application projects, worked on the process of dialog design, developed tools to assist in design, and analyzed the results of user trials of prototype applications.

Deborah Dahl. I developed the approach to spoken dialog design which is used in the Natural Language Understanding group at Unisys and used it to design dialogs for applications in the areas of retail banking and airline reservations. I also manage the development of the natural language processing engine and toolkit used to develop Unisys applications.

Position Paper

The user has completed the sequence of turns with an application where a set of related parameters were requested which the application uses to provide information to the user. The system has provided the result and the user would like to perform another transaction that requires the modification of one or more of the parameters. Today, the typical system requires the user to start over and re-enter all of the parameters again.

Reason This Is A Problem

Depending on the number of parameters, repeating all parameters when it is necessary to only change one or two, is not desirable. For example, in our mortgage quote application where the mortgage amount, term (years), type (fixed or adjustable), and points (origination fee) are the parameters, the user may want a second quote with a different term. The user must start from the beginning and re-state all parameters. This is time-consuming and frustrating for the user. Were the user talking to a human customer representative, they could explain that they would like a second transaction similar to the previous one, except for that item. The need to start over in the call and to then be required to traverse the call flow all over again, seriously impacts the usability of an automated application.

How And When The Problem Manifests Itself

Given the current state of speech recognition technology, the typical speech-based application asks for one parameter at each turn with the user. Consequently, the process of input is a lengthy one. The use of the application is tolerable when performed to completion a single time. The more often the user must perform this activity, the worse the effect on usability. To make this even worse is the frustration the user experiences when the entire process must be traversed when the change of only one, or more, parameter(s) is desired. After all, the input was entered the first time, the computer should remember it.

One advantage to human speech, over a telephone keypad, is that it allows for the provision of several parameters in a single relatively short sentence. Experienced users of telephone keypad applications memorize or write down the keypad entries that they need to make to arrive at a certain point in the call sequence. Even if speech recognition technology were significantly improved to the point where multiple parameters could be spoken by the user in a single utterance, there would still be a need to change one or more parameters without re-stating the entire request.

This problem is even more challenging in applications where the system offers choices to the user that are based on the user's earlier responses. When the user changes the value of the desired parameter, that change may require that several other parameters be changed since their current values are based on the user's original value in the item being changed. Some of the parameters requested may not be necessary in the new transaction. The application would not use those. However, the change may require the request for new parameters. Therefore, it may not always be as simple as the re-stating of the user-desired items. This can develop into a very complex scenario. When the modification of the parameters results in different application prompts, the user may become confused since he or she can not be sure which items are being used in the new transaction. In these cases, the final set of parameters being used in the transaction may need to be listed.

Some dialog design issues for the modification of parameters are as follows:

Application Examples

There are two very clear, and similar examples of the problem in applications that we have developed in our organization; a mortgage payment quote application, and a home insurance coverage quote application. The examples are similar in that they result in a calculated amount that is quoted to the user.

In both examples, the user is required to provide several parameters that are then used to provide the quote at the end. The mortgage application requires input such as loan amount, term, number of points, etc. The home insurance application requires input such as number of bedrooms, type of structure, etc.

In the mortgage payment quote application (a brief excerpt):

System: "Welcome...would you like a fixed-rate or adjustable-rate
        mortgage?"
User:   "I'd like a fixed-rate mortgage please."
System: "Fixed-rate mortgages are offered for a ten, twenty, or thirty
        year term.  How many years do you want the term of your loan to be?"
User:   "The longest term possible."
System: "OK, thirty years.  To the nearest five percent, what is the
        percent of your down payment?
User:   "I'm putting twenty percent down."
System: "Twenty percent down payment.  How many points are you willing to
        pay; one, two-and-a-half, or three points?
User:   "The minimum please."
System: "One point.  How much do you want to borrow?"
User:   "A hundred thousand is what I need."
System: "One hundred thousand dollars.  If the amount is correct say
        'continue', otherwise say 'change the last answer'."
User:   "Continue."
System: "The monthly mortgage payment for a thirty-year, fixed rate
        mortgage of one-hundred-thousand dollars, would be approximately
        seven-hundred dollars.  This monthly payment is based on a twenty percent
        down payment, and a loan origination fee of one point.  Would you like to
        get another quote, or end the call?"

At this point, the user may prefer to request the following instead of starting over from the beginning:

(1) "What would my payment be if I paid two points instead?" or
(2) "What would my payment be for an adjustable loan?"

It would seem reasonable for the user to request the first (1), since it is an parameter that would appear to require a simple re-calculation of the monthly payment. Since it is unlikely that any of the parameters following 'points' was dependent on the number of points, this may be possible. The interest rate will most likely change, since the rate is usually modified based on the number of points. But this would not be an issue since interest rate is not an parameter provided by the user.

The second sample request to change a parameter (2) is more complex. The entire set of parameters may need to change, and the type of adjustable rate mortgage may need to be solicited. The dialog dependency, on this parameter, is evident in the above mortgage excerpt in the second prompt to the user -

System: "Fixed rate mortgages are available for..."

In either case, how does the user know that they can make this kind of request? How would the system explain this capability? How complex would the resulting speech recognizer grammar be?

CHI '97 Workshop: Speech User Interface Design Challenges