Last updated: Jan. 16, 1996
A Telephone Pattern LanguageThis document is the start of a pattern-language for phone-based systems.
Add ValueContext. Trying to automate a system with a phone-based interface.
Resolution. Make the system add value as much as possible.
Discussion. An automated system (replacing a human operator) tips the balance very far towards reducing the value of the interaction. Automation should try to make up for this by trying to add value where it can.
From the caller's side, automation is a tradeoff: it's nice to be able to leave a message, but it's frustrating not to reach the desired person. There are several common ways of adding value for the caller: the ability to leave a message, the chance of receiving "targeted" or "personalized" messages, notification when the callee is on the phone, directory assistance, and others.
For the callee (who is often the purchaser or at least the heavier user of the system), the system might provide timestamps, tell who called (by name or number), provide archiving of messages, or any number of other features.
[Idea: tie online systems & phone based systems.]
Designed VocabularyContext. Describing options in a PBI.
Resolution. Use a limited vocabulary, chosen to match the set of tasks.
Discussion. Variety in expression may be a valid goal in some forms of writing, but it is not helpful in appliances. Pick particular words to refer to concepts, and use them consistently. (For example, if you "listen to message", you should also "record a message", not "make a recording".)
Minimize Expected Path LengthContext. Trying to arrange options and descriptions in a PBI.
Resolution. Minimize "path length times expected frequency" for the operations.
Discussion. Consider what operations are most common, and describe them first. This prevents people from having to listen to rarely chosen options before hearing the one they're most likely to want. If an option's frequency justifies it, you might provide special shortcuts for it.
This principle is well-established in performance engineering (see [Smith]) (as well as UI [Shneiderman??]).
Describe Then PrescribeContext. Trying to word options in a PBI.
Resolution. Describe the option, then tell how to invoke it.
Discussion. The user is trying to do two things: choose a correct option to match their goal, and figure out how to invoke that option. If the phrasing is "Press 1 to leave a message", the user has to keep "Press 1" (the system's goal) in mind while they decode and assess the option "leave a message" (their goal). By instead using a phrasing such as "To leave a message, press 1", they can match their task to the chosen option, without the distraction of preparing for the mechanics of the operation.
This approach can be carried further, listing potential options before describing their mechanics. "You can listen to this message, delete this message, or exit. To listen to this message, press 1. To delete this message, press 2. To exit, press 9 or hang up." This approach trades off a longer time of listening against two opportunities to choose a task.
Human of Last ResortContext. Trying to automate a system with a phone-based interface.
Resolution. Offer to connect to a human operator (if possible), but make this offer only after all other options have been listed. Use key '0' to invoke this option.
Discussion. People hate "phone mail purgatory," where they just want to talk to someone (anyone!) who can help. Make sure they have a way to escape.
Consistent KeystrokesContext. Trying to automate a system with a phone-based interface.
Resolution. Have at least some keystrokes that are context-independent, having the same meaning throughout.
Discussion. This lets occasional users quickly rebuild a model of what works. For example, you might consistently use '#' for 'Enter', '9' for 'Exit', and '0' for 'Operator' in all contexts.
Copyright 1994-2010, William C. Wake - William.Wake@acm.org