Kortum P. (ed.) HCI Beyond the GUI. Design for Haptic, Speech, Olfactory, and Other Nontraditional Interfaces
Подождите немного. Документ загружается.
F If possible, phrase the questions so that “yes” is the most frequent response.
F For confirmations, star can be used in place of 2 to go back and fix the entry:
“You entered 800-555-1212. If this is correct, press 1; if not, press *.”
7.6.5 Statement Phrasing
Prompt statements need to be short and clear—the user will be hearing, not
reading, them.
Keep Statements Brief
Prompts, messages, and menu selections should be as brief, simple, and unambig-
uous as possible (e.g., “To confirm your order, press 1”). Statements should be
short enough not to discourage expert users, but contain enough information to
be clear to novices.
Format Statements for Success
F System prompts should be of the form “action-object (i.e., “To do X, press
Y.”). In other words, present the available action first, and the key needed
to take the action second (“For call waiting, press 1.”).
F Avoid the passive voice. For example, do not say, “A telephone number
must be entered now.” Instead, say, “Enter the area code and phone
number now.”
F Avoid negative conditionals. For example, do not say, “If these instructions
were not clear, press 1.” Instead, say, “To hear these instructions again,
press 1.”
F System statements should present important information first to allow
users who do not wish to listen to the full set of statements and prompts to
quickly identify key information.
F Critical information should not be the very first word in an announcement.
Users with keypads embedded in the handset may not hear the first two
words following a key press as the handset is brought back to the ear.
Therefore, introduce critical information with phrases such as “You have
five...,” “There are five ...,” The number five...”
F Terminology should be consistent throughout the system.
F Terminology should match the intended audience of the interface. Avoid
jargon related to telecommunications and computers when the intended
audience is outside of these industries. For example, use “Enter the area
code and the first three digits of your phone number,” rather than
something like “Enter your area code and prefix.”
F Avoid prompts, statements, and menu labels that sound too general, as
users will often select an incorrect option before listening for one more
7 Interactive Voice Response Interfaces
252
appropriate. For example, when users are prompted with a statement that
includes wording like “For all other billing questions...” many users will
select the option for a variety of questions unrelated to billing needs.
F When referring to the system itself, or to the company or one of its
representatives, use the pronoun “we.” (“We”re sorry, we are unable to
process your request at this time.”). An exception is when referring to a
specific individual or group within the company (“A repair technician will
contact you within 24 hours.”).
7.6.6 Wording Conventions
Following conventions and using standard terminology builds on what the user
already knows.
Use Standard Terminology in Prompts
F Use the term “press” for single-digit entry (“If yes, press 1.”).
F Use the term “enter” for multiple-digit entry of phone numbers (“Please
enter the area code and then the telephone number for which you are
reporting trouble.”)
F Use “enter” to request information (“Enter your zip code now.”).
F When prompting the user for a single key press (e.g., as in a menu prompt
to press a key for a menu selection), use the “To do X, press Y” format
(“For call waiting, press 1.”).
F Refer to the DTMF keys with standard names.
F Refer to * as “star” (“To cancel this order, press star.”).
F Refer to # as the “pound key” or simply “pound” (“Enter the amount of
your payment in dollars and cents, then press pound.”).
F Refer to 0 as “zero” (“To speak with a service representative, press
zero.”).
F Refer to the number keys (0 to 9) by their digit names (“For sales,
press 3.”).
7.6.7 Metaphors
Metaphors can be powerful. While a proper metaphor can aid the user, a poor
metaphor will add confusion.
Use Metaphors Appropriately
F Choose an appropriate metaphor so that the users develop a reasonable
conceptual model of the system (e.g., voice mail is based on a metaphor of
7.6 Design Guidelines
253
the paper mail system). By using metaphors, users can develop a set of
expectations that can then be applied to the system environment, and will
help them to have a valid conceptual model.
F Reserve the use of a metaphor for places where it truly applies. Do not
label functions with names that do not make sense in the context of the
application simply to fit a given metaphor. This will confuse the user
when the name does not represent the expected action.
F The use of a metaphor should be consistent within each interface. Do not
mix metaphors within a single application.
F The use of metaphors should be consistent among applications. This is
especially important in interfaces with interacting or identical functions.
Otherwise, users who transfer between systems with different metaphors
may become lost and confused.
Apply Directional Metaphors Consistently
F If a directional metaphor is used (e.g., backward, forward), use the
numbers on the left side of the standard 3 4 keypad to indicate previous,
lower, slower, backward, and so on, and the numbers on the right of the
keypad to indicate next, higher, faster, forward, and so on. This provides
the best possible match with learned expectations and should minimize any
conflicts with other factors.
F This is a case where it may be desirable to violate the recommendation
on ordinal numbering of options. For example, if 4 and 6 are used for
previous and next, there is no requirement that 5 have an assigned
function. In some cases, it may also be acceptable to voice these choices
in order of most frequent use rather than numerically. For example,
“For the next message, press 6; for the previous message, press 4.”
7.6.8 Key Assignment
Key assignments should be chosen to simplify the interaction for the user.
Do Not Use Mnemonics
F Choices in a menu should be numbered consecutively in ascending order,
starting with 1.
F Menu choices should be numbered to correspond with the numbers
on the telephone keypad, rather than named with mnemonics, such as
“To send a message, press 1,” rather than “To send a message, press s.”
While using “w” for call waiting, “f” for call forwarding, or “s” to send a
message might seem like a good way for users to remember menu
commands, it will increase user input time and lead to errors. Some
7 Interactive Voice Response Interfaces
254
handsets do not have letters on the keys. In addition, persons with visual
disabilities memorize the position of the numbers, not the letters on the
keypad.
F The meaning of a key press must never depend on its duration. Calling
cards that require the user to press and hold star for two seconds have
violated this recommendation and should not be emulated. Using key
press duration to change function creates accessibility issues for users
with motor control difficulties and often for all users due to lack of clear
instructions. Many users hold key presses longer when frustrated—having
the function change when they do so will not improve satisfaction.
Create Functional Consistency
F Make key assignments consistent within applications, and wherever
possible, across different applications. Keys should be consistently
assigned to the same actions.
F Recognize that in new versions or upgrades to a service, reassigning a
key associated with a core function to a different function may cause
difficulties for users; they will have to then unlearn the original
association and learn the new one, resulting in errors.
F If a core function is known to be coming in the future, but is not yet
implemented, try to reserve the key for the future implementation of that
function.
F Within a menu the function assigned to a key should not change as a
result of time passing or background state changes. If the function
assigned to a key needs to change, the system should play a new
menu with the new key assignment.
Avoid Letter Entry on the Keypad
Whenever possible avoid letter entry on the keypad. If possible choose numeric
rather than alphanumeric User IDs or passwords for IVR systems. If there is a
database to match text entries against, the user should be able to enter text with
a single keystroke per letter. For example, if a customer’s name is “Pat,” the cus-
tomer should be required to only press the numbers 7, 2, and 8. Letters map onto
keypad numbers, as shown in Table 7.1.
While most keypads begin lettering with the 2 key (A, B, C), some assign Q
and Z to the 1 key. Therefore, although the preferred way is to map Q and Z onto
the 7 and 9 keys, respectively, the system should also map the 1 key to Q and Z.
When it is not possible to use a single keystroke per letter (e.g., when names are
being entered for the first time and the system could interpret the input in several
ways), the system should clearly describe the multikey method of text entry to
users.
7.6 Design Guidelines
255
Avoid Terminator Keys When Possible
F Do not require users to enter a terminator as part of a menu selection. For
example, if the prompt is “For billing, press 1,” then the user should only
have to enter 1, not 1 followed by # (where # is the terminator). If the user
mistakenly enters a terminator where one is not asked for, the system
should ignore it and not flag it as an error.
F If possible, do not require users to enter a terminator to signal the end of
multiple-digit input. For example, the system should be able to detect the
ninth and final digit of a nine-digit Social Security number entry.
7.6.9 The 0 Key
When help is provided, the 0 (zero) key should be used to access system help.
Typically, system help takes the form of being transferred to a live attendant or
of receiving recorded help information.
F If transfers to a live attendant are available, pressing the 0 key should
terminate the current action and take the user to a service representative.
The specific facility to which the system transfers the user should be deter-
mined by the context of where in the system the user is currently located
(e.g., if the user requests assistance while in the billing portion of an IVR flow,
the user should be routed to a billing representative).
F Avoid transferring the user to more than one representative.
F When no representative is currently available (busy or after business office
hours), the 0 key should lead to appropriate statements or messages.
F If the system provides online help, the help message should be specific to the
user’s context in the IVR. Once finished with help, the user should be returned
TABLE 7.1 Letters Mapped to DTMF Key Numbers
Key Letter Mapping
1 None
2A,B,C
3D,E,F
4G,H,I
5J,K,L
6M,N,O
7P,Q,R,S
8T,U,V
9W,X,Y,Z
7 Interactive Voice Response Interfaces
256
to the same system state that he or she was in prior to the help request. Incom-
plete actions may be cancelled, however. If they are, the user should be asked
to start the action over again.
F If multidigit input is expected e.g. a phone number, and the user enters
ZERO and then times out, the system should treat this as a “ZERO pressed
for help” and transfer to a service representative or give con text-specific
help.
7.6.10 The * Key
The * (star) key is typically used to cancel user input, move backward in a
sequence, or move upward in the menu structure.
F
Cancel input string:
If the user is entering a string such as a telephone number
or pass code, pressing * should discard the digits that have been entered and
return the user to the prompt preceding the entry of the digits.
F
Back up to previous action:
In functions that require many steps, pressing *
should take the user back past the last completed step, and return to the
prompt to allow the user to perform that step over again.
F
Exit submenu:
If the user is at a lower-level menu, pressing the * key should
take the user back to a higher-level menu, perhaps even to the system’s main
menu.
F
Terminate call:
The * key can be used to exit system and terminate call.
For some walk-up applications where users are expected to be unfamiliar with
IVR conventions, a context-specific help message tells users where the * key is
located on the keypad the first time that it is mentioned or used.
Use the * Key to Its Best Effect
Since the * key cannot provide
all
of the functionality outlined in the above exam-
ples at any one point in time, use of the key in any particular instance should
depend on where the user is in the application. In other words, the star key will
have different results depending on whether the user is currently
F Entering a numeric string (the user will be taken back to the prompt for the
numeric entry field)
F In the middle of a multistep function (the user would be taken back to the
prompt preceding the last completed step)
F At a lower-level menu (the user would be returned to the higher-level menu
that the lower-level one is nested within)
F At the highest-level menu in the application (the user would then exit the
system)
7.6 Design Guidelines
257
Developers should carefully evaluate the entire application to determine
where the * key should return the user at any given point, and assign the func-
tionality of the key accordingly.
Special Uses of the * Key in Voice Messaging Systems
If the user is recording a message, greeting, or name, pressing the * key should
stop the recording, discard what had been recorded, and return the user to the
prompt preceding the record tone. In the process of logging in, if the user
realizes that the system is assuming the wrong mail box, he or she should be
allowed to press * during t he password prompt and be taken back to the mailbox
prompt.
7.6.11 The # Key (Terminate, Skip Ahead)
The # (pound) key is typically used as a terminator for variable-length user input,
to confirm user input, or to move forward in the system.
Use the # Key as a Terminator
F When a terminator is needed, use the # key. Time-outs are always
accepted as terminators in these cases as well.
F Use # to indicate the end of a variable-length input string (“Enter the
amount in dollars and cents, then press pound”). A terminator is required
whenever the input can be of variable length. A terminator should not
be used with fixed-length entries (e.g., phone numbers). When use of
the pound key is required, the prompt must explicitly state this
requirement, as in the example above.
F Do not use the # key as a terminator as part of menu selection. For
example, if an option is “To use our automated system, press 1,” then the
user should only have to enter 1, not 1 followed by #.
F If a user enters the # key during the playing of an interruptible
announcement, the announcement should immediately cease and the
system should proceed with the next step. The # key is not in the dial-
ahead buffer, as its action was to interrupt the announcement and it has
acted.
F The # key can also be used to do the “usual” or most common choice at a
menu. An example would be selecting a day of the week, where “today”
varies, but is the most common choice. “For today, press pound. For
Monday, press 1. For Tuesday...”
Special Uses of the # Key in Voice Messaging Systems
F The # key should be used when a terminator is required to end a recording
(a time-out should also be accepted as the terminator).
7 Interactive Voice Response Interfaces
258
F If the user is listening to a prompt that precedes a record tone, pressing
the # key should skip the rest of the prompt and take the user to the
record tone (e.g., when recording a message, greeting, or name). This also
applies if the user is listening to a subscriber’s greeting. The # key should
skip the greeting and go straight to the record tone to leave a message for
the subscriber.
F If the user is listening to a voice mail message, pressing the # key should
stop playing the message and take the user to the next message.
7.6.12 Prompts and Feedback
The user should receive feedback from the system to confirm actions, warn about
dangerous actions (e.g., request explicit confirmation from the user), echo user
input, explain error conditions (e.g., an option is not available), and tell the user
what the system is doing.
F If something has been added or deleted, confirm each addition or deletion as it
is requested, then summarize overall changes at end of add/delete activities.
F Present the next prompt or statement within 0.75 of a second (750 milliseconds)
after a user makes a menu selection.
F When possible, avoid using the words “to,” “too” or “for” in menu prompts
where they may be confused with the option keys 2 and 4.
Provide Appropriate Information about System Delays
F A
small
delay is defined as between 750 milliseconds and 3 seconds. This
delay is noticeable and undesirable to customers, but no announcement
explaining it
is required
.
F A
medium
delay is defined as between 3 and 8 seconds. This delay is
noticeable and undesirable to customers; a short announcement
explaining the delay
is required
.
F A
long
delay is defined as between 8 and 30 seconds. This delay is
noticeable and undesirable to customers; a short announcement with an
estimate of the delay
is required
. Music should be played during the wait.
Music should not be a “canned” file that starts in the same place every
time the customer experiences a delay.
F An
extreme
delay is defined as any delay longer than 30 seconds. This
delay is noticeable and undesirable to customers; it
is required
that every
30 seconds the user hear an updated announcement with an estimate of
the remaining delay, and music should be played between these
announcements. Extreme delays will cause customer dissatisfaction.
Music should not be a “canned” file that starts in the same place every
time the customer experiences a delay.
7.6 Design Guidelines
259
Get Required Information Early
If an application requires customer information, collect it before completing
steps that are dependent on correct entry of that information. For example, if
the telephone number is required to access account information, get and confirm
it before asking what type of information the customer desires.
Tell the User the Number of Digits to Enter
When the user is prompted to enter numeric input of a fixed length (e.g., a Social
Security number), the prompt should state the number of digits that must be
entered, as in “Please enter your nine-digit Social Security number.” Exception:
In cases where a fixed-digit number is being collected for security purposes, the
number of digits required
should not
be stated.
Tell the User H ow to Indicate That Number Entry Is Finished
When the user is prompted to enter numeric input of a variable length, the
prompt should ask the user to enter a terminator when data input is completed.
However, a time-out will also be accepted to terminate input. The # key should
be used as the terminator key.
Always Confirm User Input
F Always provide a way for the user to confirm (or cancel) input. This can
be provided as an explicit, prompted option, such as “If this is correct,
press 1. If not, press 2.”
F The system should read back user input in proper phrasing. In many
cases, the system should just read back the user’s input exactly as it was
entered. For example if the user enters 1-800-555-1212, the system may
ignore the “1,” but when confirming the entry it must ask the user to
confirm all 11 digits entered, as in “You entered 1, 8, 0, 0...” However, if
the system reports the time to the user, it should be read back as “eleven
o’clock,” not “1, 1, 0, 0.”
F Repeat back to the user long data entries for confirmation with
appropriate pauses. For instance, if the user is asked to enter a Social
Security number, the system should respond with something like “You
entered 123 <pause> 45 < pause> 6789. If that is correct, press 1. To re-
enter, press 2.” It is critical that phone numbers be read with proper
phrasing and not as a 10-digit string.
Use a Tone to Signal the Start of a Recording Window
Voice messaging systems should have a distinct record tone, distinguishable
from any other tones used in the system. The tone used to indicate that the
recording is starting should be a single beep, of 440 Hz frequency, and 0.5 second
(500 millisecond) duration.
7 Interactive Voice Response Interfaces
260
7.6.13 Errors
Error statements and prompts should be of the following format:
F Optional error tone (standard double beep, as in the following example).
F What went wrong (and the current system status).
F Why the error happened.
F What the user should do next, possibly including more information than was
presented in the original prompt.
Example
: <beep-beep> “Access to your account has been denied.” (
what
)
“The phone number and PIN you entered do not match our records.”
(
why
) “Please re-enter your area code and phone number.” (
how
)
F After a particul ar number of consecutive errors (two or three), the s ystem
should take special action, such as transferring user to a live attendant.
An error count on one prompt should generally not carry over to other
parts of the interface, but should b e cleared whe n user resolves the error.
Forexample,inanorderingsystem,a user might enter a phone number
incorrectly twice before getting it right. The system should not then imme-
diately transfer the user if he or she makes a
subsequent
error in the order-
ing pr ocess, even though that would be the third error since enter ing
the system.
F A single user error should not cause the system to disconnect, unless it is a
security requirement.
Use the Standard Error Tone
If a tone is used to indicate an error, the tone should be a double beep, and should
be 440-Hz frequency, 100 milliseconds on, 50 milliseconds off, and 100 milli-
seconds on.
Do Not Make the Error Message “Bad”
F Avoid negative words and phrases like “invalid response,” “error,”
and so on.
F Error messages should be written so as to avoid compromising system
security. In parts of the application where security is an issue (e.g.,
entering the system, changing account status), the system responses
should not provide more information than is needed. If a phone number
and PIN are required to authorize use of a system, do not prompt the
user with the digit length of the PIN, and do not give individual
confirmations on either the phone number or the PIN. If either or both are
incorrect, use the error message “The phone number and PIN you entered
do not match our records.”
7.6 Design Guidelines
261