Show TOC

Background documentationVoice Application Design Locate this document in the navigation structure

 

Consider the information provided in the following sections when you are designing a voice application. This information helps you to plan your voice application implementation effectively.

Roles

You need to consider the following set of users in your voice project:

  • VUI designer

    Person who is responsible for designing the dialog flow of a voice application.

  • VUI implementer

    Person who develops a voice application using the voice tools.

  • Quality assurance team

    Team responsible to check for certain quality standards in the voice application. These are standards are specific to an organization.

  • R/3 or Web service expert

    Person responsible for creating and maintaining back-end data and web services.

  • Business process expert (BPX)

    Person who has the business knowledge required to make business process innovation happen in real time by adapting, composing, and executing end-to-end business processes using composition software tools and enterprise services.

Design Guidelines

Consider gathering information on the following points when you are implementing a voice application:

  • Objective

    What do you want your voice application to accomplish?

    For example, you may want to develop a voice application that offers banking solutions.

  • Audience analysis

    Who are your end users or target groups?

    For example, customers who want to open new accounts and the existing account holders with the bank are the end users.

  • Content management

    What content, structures, and hierarchies do you need to organize?

    For example, based on the previous history with the bank and the amount deposited by the account holder you can customize the menu to provide better service.

  • Navigation architecture

    How do you want the caller to move through the application? What choices do you offer to the caller?

    For example, once the customer performs a transaction you can either direct him or her back to the main menu or provide a new menu based on the transaction.

  • Interaction flow and design

    What prompts, grammars, error messages, or help functions do you want to use in the application?

    Note Note

    Grammars are either spoken words or touch-tone input (from the caller) that the system can recognize. The NetWeaver Voice resources include a grammar that you can download during the installation. It can also integrate third-party grammars (external grammar files) into your voice-application models.

    End of the note.
Business Requirements

To fulfill the design objective, you need to gather the business requirements. Here are some suggestions for various situations:

  • If you are replacing an existing phone service, call this service and document all the available features that you find in the application.

    If you have access to design specification for the old service, use them. However note that design specifications loose accuracy over time.

  • Record the existing phone service to analyze the system and document the bugs later in the process.

  • Discuss the prompts and system responses during requirements-gathering sessions. This is important since customers concentrate on the system response.

  • In the case of banking applications, find out whether or not the bank allows users to transfer funds. If transfers are allowed, you must know the exact conditions under which the bank permits them. You should also consider possible causes of failure.

Design Effort

The design effort for voice applications partly depends on the technology that you choose. A few comparisons and suggestions are given below, taking the cost and quality of these technologies into account:

  • Speech recognition versus DTMF (touchtone):

    • DTMF is cheaper

    • Speech recognition is more powerful

    • Speech recognition systems provide better customer satisfaction

  • Text To Speech (TTS) versus recorded prompts:

    • TTS is cheaper

    • TTS is more flexible and handles dynamic data more easily

    • Recorded prompts sound better

    • Recorded prompts are easier to understand and less tiring to listen to

  • Computer Telephony Integration (CTI):

    • CTI is only necessary in cases where you have call center agents

    • Properly incorporating CTI in the voice application is the key to a good customer experience

      Note Note

      For example, avoid situations in which callers provide customer data first to the system and then to the operator.

      End of the note.
Design Basics

Below mentioned are some voice user interface (VUI) design basics to consider:

  • The mode of communication in a voice application is serial in nature. This means that you cannot perform more than one operation at a time

  • A VUI cannot be scanned quickly like a GUI

  • The caller loses interest if you convey too much information at a time

  • A VUI does not store the responses of an action and expects the user to remember them most of the times

  • Natural language increases usability but also increases the cost of development

Here are some VUI-design dos and don'ts:

  • Limit the length of the menu to five items so that the caller can remember the options easily

  • Make sure that all the elements in a menu are logically related to each other

  • Be consistent with parts of speech inside a menu

  • Use appropriate prompting:

    • Do not prompt the caller as follows:

      You can say 'create an order', 'order status', or 'my account'.

    • Do prompt the caller as follows:

      You can 'create an order', 'check the order status', or 'check your account'.

  • Make sure the welcome messages match the brand of the company and the service that you are providing

  • Do not over use formal language in the welcome messages

  • Consider the following points on the language usage:

    • Use natural sounding dialog to put the caller at ease.

    • Do not say 'Your call is very important to us'.

    • Do not say 'Please listen carefully as our menu options have changed'.

  • Note the following points for a menu:

    • Options that are used most frequently should be presented first

    • The first element in the list sets the user's expectations for the rest of the list. (priming).

    • The last element in a list is the easiest to remember (recency).

    • The user might not listen to subsequent items after making a choice.

    • Do not choose multiple items that are similar acoustically

    • Pick good menu styles and be consistent in using them:

      • You can say 'check my account balance', 'report a problem', or 'talk to an operator'.

      • You can say 'fund transfer', 'account balance', or 'operator'.

  • When working with speech recognition systems, use longer words as they are more acoustically distinct and are recognized more easily

  • If you are using both DTMF and speech recognition in your voice application, consider the following points:

    • Where speech recognition becomes difficult, use DTMF as a fall-back option

    • Provide expert users with DTMF shortcuts.

    • Be consistent with mapping DTMF commands to menus.

      For example, use you can say 'fund transfer' or press 1, 'account balance' or press 2, or 'operator' or press 3. This would be predictable for an expert user even if you do not play the DTMF choices since they are sequential.

Error-Condition Considerations

Business owners cannot identify all the potential error conditions that might occur in a voice application. Creating new prompts for the various error conditions is not a simple task.

Here are few recommendations to minimize the effort of identifying error conditions:

  • Plan for at least two separate recording sessions, one after the sign-off of the design document and the other at the end of the final bug testing phase

  • Use any of the following options:

    • Text To Speech (TTS) or

    • Recording of temporary prompts in your own voice