|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2004 --> Designing a telephone-based user interface
Vous êtes ici : Essais --> 2004 --> Designing a telephone-based user interface
By Geoff Hart
Previously published as: Hart, G.J. 2004. Designing a telephone-based user interface. Intercom February:9–11.
"Voicemail hell" and "voicejail" are just two of the epithets that have entered our language in response to the widespread use of computerized telephone-answering and call-routing systems. One joke goes along the following lines: "If you're calling from a touch-tone phone, press '1' now. If you're calling from a rotary phone, hang up and call back from a touch-tone phone." You're a rare person indeed if you haven't recently found yourself trapped in hostile telephone system ostensibly designed to make your life easier.
Why are these systems so painful to use? Because they're often designed by people with little knowledge of what callers hope to achieve by using the system, and even less knowledge of how to design a system that meets those needs. If this sounds an awful lot like software development, that's no coincidence. And, just as in software development, the solution may be to involve technical communicators in the system design. Our ability to empathize with the system's users lets us act as their advocates to produce a design that meets their needs. Moreover, our experience working with complex interfaces lets up help developers to produce simpler, more usable systems.
In this article, I'll discuss some of the problems posed by telephone-based interfaces, propose some solutions, and stress the need for testing these solutions to develop a body of "best practices" similar to those that are being developed in related fields such as Web design. After all, the techniques used to reduce the risk of becoming "lost in cyberspace" will also apply, with appropriate modifications, to enabling the successful use of telephone-based interfaces.
From the user's standpoint, computerized telephone systems have the nominal goal of connecting users to the right person (or the right recorded tidbit of information) as quickly and easily as possible. The companies that offer these systems may have other, sometimes contradictory goals for the system, such as eliminating the need for receptionists or holding callers captive long enough to make them listen to a sales pitch. I'll focus on designing a system that meets the user's needs, which is where we can apply our expertise; however, you should be aware of conflicting goals that may require some diplomacy and persuasion to circumvent.
Callers who know exactly who they want to contact should have an efficient means of establishing that contact. If they know the person's extension or name, they should be able to use this information immediately and completely bypass the rest of the interface. Many well-designed interfaces begin with a phrase such as "If you know the person's extension, dial it now, or press '1' to access the company directory." This kind of interface provides the same fast access to a function that power users expect in software, combined with a wizard (the menu choices that follow) to guide less-skilled users deeper into the system. A truly user-friendly system will also let the caller press "0" or some other key immediately to reach a receptionist. It's dismaying how many systems provide no way to reach a human without navigating through a convoluted menu hierarchy—only to reach the voicemail of someone who's away on vacation for 2 weeks.
For callers who continue past this first decision point, the system must guide them gently toward the correct departments. If you don't understand a caller's range of possible goals for calling, you can't provide efficient access to these departments. Identify those goals by performing at least a basic audience analysis. Such an analysis can begin with your company's corporate structure (for example, one menu choice for each department), but shouldn't stop there. Just as a good software user interface builds a mental map that links the user's needs with the software functions that meet those needs, a telephone-based interface must build connections to the people who will meet the caller’s needs.
Once you understand the relationship between caller needs and the people or departments that will satisfy those needs, you must develop a menu structure that links the two—the map we considered in the previous section. Here's where we can borrow from the toolkit of Web design. Many studies of menu hierarchies have convincingly demonstrated that broad, shallow hierarchies, with many initial choices and few subsequent "clicks" required to reach the final destination, meet user needs most effectively. Of course, the breadth and depth of the optimal hierarchy vary from study to study and are likely highly sensitive to the unique features of each situation.
Why does this approach work? Because it quickly offers callers a range of choices that present all the main areas they may want to reach. Moreover, it reduces the risk that callers will dive deep into the hierarchy only to discover they've reached the wrong destination. Studies of menu hierarchies suggest a promising beginning for developing effective telephone-based interfaces: Provide enough choices early on to minimize the perceived risk of following the wrong path—and minimize the penalty that results if users do take the wrong path. A shallow hierarchy means that those who end up in the wrong place have a shorter path to retrace before they can begin their search again. The same principles apply to a phone system, but they are even more important because there's rarely a "back" button that lets callers retrace their path. Wherever possible, provide such an option by adding a final "Return to previous menu" choice or using a standardized key (for example, *) to return to the previous menu.
As has been the case for the Web, research will eventually provide guidelines on the optimal combination of depth and breadth for various telephone applications. Until it does, aim to use as many of the ten numbers on the phone as is efficient. In this case, an "efficient" design must balance several potentially conflicting needs. As you design, try to do the following:
The nature of the information provided by a telephone interface poses inherent problems. Most people with normal vision are far more proficient with their eyes than with their ears, and it's difficult to remember locations within a complex menu structure in the absence of visual indicators. Phones with visual readouts would greatly simplify the navigation of menus, but these phones are not yet common or well integrated with menu systems. The problem of remembering where you are in a telephone interface is another strong argument for using a shallow menu hierarchy. A shallow menu places fewer demands on short-term memory, and thus makes it more likely that callers can relate their current location to the desired destination.
How do you help callers construct a map of where they are and connect that map to where they want to go? Provide simple clues akin to the "breadcrumbs" (lists of the path followed to reach a specific page) that some Web pages use. The auditory equivalent of breadcrumbs might be a short verbal reminder of where the caller is. A simple message such as "Customer service menu," followed by a list of options, immediately reveals the current location and frees the caller to concentrate on where to go next.
In the previous section, we saw the importance of being able to backtrack. Knowing that it's possible to return to previous menus without calling again reduces the stress of using the system. Callers can relax and concentrate on the task at hand. If you provide a "bail-out" option that lets callers reach a person if they're overwhelmed, you can further reduce stress. Complex menu systems are less frustrating if callers know they can assert some control over their fate, even if that only amounts to asking someone for help.
Patience and attention are both scarce commodities, so design the menu announcements to be as concise as possible without sacrificing understanding. This is a particular challenge, because clearly pronounced text takes more time to deliver than hastily spoken text, and because all spoken text takes longer to listen to than to read. As a result, spoken text can severely test the listener’s patience, particularly in complex menu systems that offer many options. A good editor, particularly one who has experience in copyfitting (shortening text to fit the allotted space), can be a valuable ally in creating such messages.
One serious problem many designers of telephone-based interfaces face is that some department—often marketing—forces them to add advertising messages before the menu choices. Callers like these messages about as much as users like the popup ads that proliferate in Web browsers or the intrusive boasting about a product that still appears in the occasional user manual. If you can't persuade The Powers That Be to eliminate these messages, at least try to reach a compromise solution that will not alienate callers. Keep this text as short as feasible, and try to present it while callers are on hold rather than while they're trying to work their way through your menus.
Avoid long introductions and platitudes such as "We at XXX really appreciate your business and hope that you'll find our voicemail system helpful and efficient to use." If you really appreciate your customers, you won't waste their time with such pap, nor will you try to persuade them that the technological solution they've encountered is more effective than the receptionist it replaced.
Part of the writing and revision phase involves what I call “proofreading in the actual medium”—the recognition that words intended to be spoken aloud cannot be tested except by speaking them. Edit these words carefully for brevity and clarity, but don't stop there: Make sure that someone takes the time to listen to the recorded messages. That's the only way to ensure clear and unequivocal results. It’s easy to fall into old habits such as writing “and/or” or “e.g.” for spoken text, or pronouncing words sloppily or incorrectly when recording a message.
In addition to the "Where am I?" information, consider building in some of the kinds of standard user-interface feedback we're accustomed to in a software interface. For example:
The suggestions I've made thus far relate primarily to quantifiable factors. However, callers differ in their motivations and their states of mind. Sensitivity to these differences will make even a poor design seem better, and will improve a good design. For example, in what order should you list the options in a menu? A rational approach might suggest that the menu choices that are most often used should appear first, with the remaining options listed in order of decreasing popularity. But what if a small proportion of your callers will be highly stressed when they reach your menu system—as in the case of callers seeking assistance in a real or perceived emergency? Other callers are probably sufficiently relaxed to wait a few extra seconds to hear the choice they seek, but callers under stress will benefit from having their menu choice appear first.
Subtle consequences can arise from design decisions. For example, in Quebec (a majority French-speaking province), French is often listed as the first menu choice and assigned the number 1, with English assigned number 2. To some, this suggests that English speakers are second-class citizens. A compromise solution might be to offer the chance to "Press 1 if you want your options in English," followed immediately by the French options. This approach gives English-speaking callers immediate access to the text in their language, but French callers don’t need to do anything to hear the options in French. Perhaps more effective still, particularly for more than two languages, you could propose that the system designers provide a separate phone number for each language.
What other psychological factors might affect how your callers interact with the phone system? If you can't answer that question, you need to put yourself in the callers' shoes. Once you've found out why they're calling, and how they're feeling as a result, you can take steps to put them at ease, or at least to minimize their stress. But first you've got to know what the problems are.
All the suggested approaches in this article must be tested and confirmed for any given audience. Though the suggestions are sound, and some are based on good research, telephone menu systems are a relatively new kind of interface that is unfamiliar to most of us. This situation calls for careful testing, with a clear focus on the user's needs.
©2004–2024 Geoffrey Hart. All rights reserved.