A Telephone Pattern Language

Posted on by

This document is the start of a pattern-language for phone-based systems.

  • GOMS – did they analyze phone systems?
  • Same key for same function everywhere (e.g., 9 to exit, # for enter).
  • Option for reaching a human – put it last.
  • Shortcuts? Speed-dial keys.
  • Added value. Rolm: tells who called. Multiple prompt levels. Timestamp on messages.
  • Describe an option, then give the number to dial. (This reduces short-term memory needs.)
  • Take advantage of processing to remove ambiguity. Example: phone that lets you type person’s name. Bentley has an example of this in a real phone directory.
  • Allow people to interrupt the machine.

Forces

  • Sequential nature of interface, makes more demands on STM than visual systems.
  • Limited keyboard
  • Low ‘balk’ level of callers

Examples/References

  • Grunt (Schmandt)
  • Elizabeth Mynar (sp?)
  • CHI from last few years
  • TOIS from last few years

Add Value

Context. Trying to automate a system with a phone-based interface.

Forces.

  • It is easiest to automate as little as possible.
  • If automation provides no value, people won’t use the system.

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 Vocabulary

Context. Describing options in a PBI.

Forces.

  • Slow interaction speed
  • Range of usage frequency (some users are heavy, many users are occasional users)

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 Length

Context. Trying to arrange options and descriptions in a PBI.

Forces.

  • Many options are available.
  • Sequential interaction

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 Prescribe

Context. Trying to word options in a PBI.

Forces.

  • People have limited short-term memory.

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 Resort

Context. Trying to automate a system with a phone-based interface.

Forces.

  • It is often easiest for a caller to just speak to a human.
  • If the automation is to reduce the operator’s load, users must find it preferable to mostly deal with the machine.

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 Keystrokes

Context. Trying to automate a system with a phone-based interface.

Forces.

  • A variety of options are available.
  • Users have limited memory and patience.

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.