Human Factors and Voice Applications
(Continued from Part 1)
Compelling Applications
Another dimension of application quality that goes slightly beyond usability is how compelling it is. If the application is not compelling, consumers may use it once or twice but may find alternative methods more interesting or fun. Some of the things that make applications compelling are the personality and voice characteristics of the prompts. Another is the use of sound effects or music. Another is variety within the application so that the user experience is not always the same.
Personality or Not?
This is a stylistic consideration that may make the application seem more interesting to a caller. It is not a substitute for a usable application. One can have a usable application that has a boring personality.
To complete a task the user needs clear instructions of their options and a reasonable grammar. But an interesting personality might make them more motivated to try. After several occurrences, however, the novelty of the personality can wear off. What makes an interesting demo may not make a successful application. A demo may only be played with once or twice. A successful application will be used repeatedly over time.
Some other design decisions that should be made include:
- Use text to speech (TTS) or stored speech: While it may be expeditious and frugal to write an application using TTS, many people still do not find TTS pleasant or acceptable when given the choice. On the other hand, some people prefer the cyber sound of TTS over stored speech because the application is indeed a machine and should sound like one or because they like the high tech quality a TTS voice gives to an application. Understanding the users and the usage context will guide this decision.
- Prompt Personality: When using stored speech, questions invariably come up about the sex and personality of the speaker. There are "it depends" answers to such questions. It depends on the subject of the application. It depends on the quality of that particular voice.
The particular voice personality that is selected delves more into creative entertainment than usability. The only comment I dare make here is that there is probably some interaction between the application content and an appropriate personality.
- Prompting Style: The degree to which a prompt sounds conversational or command-like has significant implications for the grammars. A command-like prompt is explicit to the caller about what the command options are. A conversational style may be more open-ended. The more open-ended the prompt, the more natural it may seem to the caller. But when a prompt is more conversational and open-ended, the caller may feel they have more latitude with what they can say. When the caller engages in an open ended dialogue the risk increases that they will say something that is outside the grammar.
Application Complexity
Generally, the Keep it Simple, Stupid (KISS) model works well with speech applications.
Complex applications may provide more functionality than simple applications, but they might also cause usage problems. Two aspects of application complexity are:
- How many speech to system interactions are there?
- How many different things can the person say during each user-system interaction?
The more times a user must interact with the application, the greater the chance that the user or the recognition engine will make an error. Error recovery is the toughest part of good user interface design. Users do not like it when they are not understood. When there are more interactions, the application takes longer to navigate, the task takes longer to complete, and the risk of errors increases.
A second dimension of complexity is the perplexity. Perplexity refers to how many different things a person can say within a particular state. When an application allows users to say many different things, they may not remember them all. Or, they may remember a synonym. Second, with a larger grammar, the recognition accuracy may suffer because the probability increases that some speech utterances are acoustically similar to other speech utterances, thus confusable by the recognizer.
Other good design practices will make the application usable. Using a language that is familiar to the user will make the prompts easier to understand, and will make the commands seem more intuitive and easy to recall. Using a consistent language will have the same effect. And, as a general guideline, it is probably best not to include more than 6 or 7 options per step.
Errors
The issue of imperfect recognition is what makes speech applications different from other types of applications. Because of this imperfection, much of the user interface design work focuses on error handling. The user errors are utterances that are not anticipated in the application and therefore will not be recognized. Or worse, they might be misrecognized incorrectly or substituted for a different command.
In a typical PC or telephone IVR application, there is a manageable set of possible inputs. For example on the phone, the user can press any of the 12 keys on the keypad, and the number pressed is recognized by the system 100% of the time. The application can be designed to ignore inputs with no associated option. The range of possibilities is known.
In a speech application, however, the user is not confined by anything except that the input be audible. They may say anything. And will. Now the system can certainly ignore odd inputs, but if the aberrant input is similar in sound to something the system expects, then that aberrant input could be misinterpreted.
The other thing that is different when compared to a GUI is that the information needed by the user to help them figure out what to do comes one chunk at a time (serially). Only after one option has been played can the next one be offered. GUIs, on the other hand, can present many options or controls together (in parallel).
How do we know what people might do so that we can design it in? In many cases we can make good guesses, but we are not always right. That is the reason behind iterative design and testing. Letting actual users interact with the system will allow you to observe first hand what someone might say when given the prompt stimulus. If many of the users say things outside what is expected, the grammar can be extended to include those things, or the prompt can be re-written to stimulate different spoken utterances.
Error Handling
When an application error occurs for example a misrecognition, a message like "an error has occurred" is not helpful. It is better to tell the caller what to do next, for example, "please repeat" or "I didn't get that", or "please try again." These phrases are ambiguous with regard to the nature of the error and will work for both in-grammar and out-of- grammar recognition decisions.
In many cases it is a good idea to follow up that phrase with a list of available commands, lest there is confusion about what is allowable. When combined with the more generic phrase above, it is a graceful way to ask the caller to repeat from the following list of available commands.
There may be undetectable speech energy. It may be that the caller did not say anything. Or, it may be that the caller spoke too softly. The above phrases work for either case, but it is less helpful for the soft speaker than a prompt that says "I didn't hear that," which might stimulate a louder reply on the next try. If the caller never did say anything, a prompt saying "I didn't hear that" might be irritating and provoke a reaction like "of course you didn't hear that. I didn't say anything." The caller might even say that out loud
Parting Thoughts
Although speech is the most natural way for people to communicate, machine understanding differs dramatically from human understanding. Humans can easily understand poorly pronounced words from the context. Speech recognizers have more difficulty. Humans can ask clarification questions about meaning and word recognition. Speech recognizers have more difficulty. Humans can detect emotion, emphasis, and intonation. Recognizers cannot. To make an effective human-machine dialogue, effort must be made to experiment with the application and to make modifications based on human speech behavior. This will help to reduce the guesswork and to enhance the user experience.
back to the top
Copyright © 2001 VoiceXML Forum. All rights reserved.
The VoiceXML Forum is a program of the
IEEE Industry Standards and Technology Organization (IEEE-ISTO).
|
