The Art and Business of Speech Recognition: Creating the Noble Voice

When the designer has a strong concept and a complete set of ideas with which to express it, the task of designing the call flow can begin. This starts with representing it graphically, then mapping it into a textual form. Call flow simply refers to the structure of the design. This call flow takes callers through a series of states during which they will either be asked to respond to a question, listen to some information, or both.

In most applications, the first state is typically called the welcome state, in which the caller is welcomed to the application. At this point, depending on the application, the caller may or may not need to be identified. A home banking application would require the caller's account number, for example, but a purely informational application, such as a voice portal, would not.

Using the home banking example, the application would then need to verify the caller's identity by asking for a password or social security number. This usually takes the caller to the equivalent of a main menu ”the starting point from which the caller can move into several states to get account information, transfer funds, set preferences, and so on.

When designing the call flow, the objective is to define the structure of the application. This can be as simple as creating a typical flowchart diagram. However, because the call flow and the prompt text are closely linked, it's often helpful to include notes describing how certain complex situations will be handled. The actual writing of the prompt text will come later.

Figure 5.1 illustrates a rudimentary call flow diagram, designed to show only the big picture of how people will move through the various states in the application.

Although the call flow diagram is a depiction of the structure of an application, it can also be used to convey design ideas and to help the designer think about various solutions. In my diagrams, I may not even draw all the arrows or include all the boxes if I need to describe a complex situation and I haven't quite worked out all the details. Instead, I might just draw some gray arrows and write a note to the reader describing the behavior that should logically follow, and flesh out the details later when I've gained more information or after I've had the opportunity to review the design.

A Real-World Example of a Call Flow

Let's explore the different ways to structure a call flow using a real example. I once designed a system for a large wholesale distributor that allowed its retail customers to call in and report two kinds of shipping errors. The client wanted the system to handle these errors and catalogue them appropriately.

This company shipped products to its retailers almost every day. Its speech-recognition application enabled retail staff (usually stock clerks) to report shipping errors and receive a credit toward their next shipment. The two types of shipping errors that could occur were

• A "shortage" ”when an ordered item was missing from a shipment, or

• A "mis-pick" ”when an incorrect item was substituted for an ordered item in a shipment

How might a designer create a call flow to handle this? The most common way that I've seen people design the solution looks like the one in Figure 5.2.

Although this approach would work, there are better ways to do it ”if we first consider a few relevant factors. First, we need to understand the callers who would use the system. In this example, they were most often stock clerks ”low-paid, entry-level workers with little interest or incentive to learn the manufacturer's jargon and processes. Instead, I opted for a way to handle the situation without requiring callers to answer questions like "Was there a shortage or a mis-pick?"

When we examine Figure 5.3, we can see overlaps and similarities in the structure.

Figure 5.4 shows how you can streamline the design and modify the approach by simplifying the questions for callers.

Often when I present this example, people ask me how it can handle the reporting of shortages and mis-picks to appropriate databases if they are collapsed from two states into one. This is an instance where a good programmer will decide how best to devise a reporting mechanism for this interface without compromising the design. The designer's objective and responsibility are to ensure the most elegant call flow, not to force the programmer to structure things in any particular way.

In this example, the programmer could decide either to

• Build one state that handles all the complexities (but may involve more coding challenges), or

• Build several states (which may allow for easier coding and testing)

Either way, it's the programmer's decision ”not the designer's.

The Top Five Tenets of Call Flow Diagram Design

1. Ensure that there's a one-to-one correspondence between the call flow and the diagram that represents the call flow (that is, each question or statement is represented in the call flow diagram).

2. Write a one-page, high-level overview of the entire application so that it's easy to see what functions the application will perform. This should be supplemented by as many detailed diagrams as necessary to describe the specifics.

3. Ensure diagrams are easy to read with descriptive words for each state.

4. Number all states in the diagram to facilitate searches within a word processing application, aid in visual searches when discussing the document with clients , and divide application functionality numerically (for example, all states beginning with the number four are regarding Funds Transfers, states beginning with the number five are regarding Account Balances, and so forth).

5. Organize and present the elements in the diagram for clarity, intelligibility, and easy navigation along the main path .