Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing | Tools | Documentation |

7.1 Manuals
        7.1.1 The Detailed Task Instructions
        7.1.2 The Command Reference
        7.1.3 The Super Index
7.2 On-Line Help
7.3 Training
7.4 Customer-Support Phone Lines


7.4 Customer-Support Phone Lines


Phone support is a huge cost for a successful product, and a good motivator for more attention to usability. Do the arithmetic by multiplying out two five-minute phone calls per customer by the number of customers: for 100,000 customers that's a million minutes on the phone, or about five years of working days. If you cut that back to one call by improving your design you're saving a lot of money directly, to say nothing of the value of increased customer satisfaction and productivity.


In setting up an effective customer support line, the three keys are training, tracking, and -- once again -- task- centered design. Training should be obvious. The people answering the phone should have the answers, or know where to get them, and they should have some basic training in phone communication techniques. Tracking refers to the user's questions, NOT the users themselves. You want to know what problems the users are having, even if they are problems that seem to be "the users' fault." Those are the problems you should be addressing in the next upgrade of your system.


And again, task-centered design. If your company already has products on the market, then you have some experience with the kinds of problems users will have. If not, you can probably imagine the categories of questions that will arise: how-to questions, software bugs, compatibility problems (with other applications, or hardware, or the operating system), questions about upgrades, etc. Imagine some specific questions in each of these categories, and then get together with someone else in your design group and act out the interaction that an imaginary user would have with your phone support technician. This is a walkthrough-like technique that can suggest modifications to both the phone-support system and the supported product, and it can also be used to train the support technicians.


Communication between a knowledgeable technician and a less- experienced user will always be problematic, and it's even harder over the phone than in person. The HyperTopic in this section gives some suggestions for improving communication. There's nothing surprising about these guidelines; any user who has dealt with on-line help would have similar ideas. Keeping in touch with the user community after your product is on the market will suggest additional improvements.


As a final suggestion concerning phone support technicians: be one! Customer calls are a great source of feedback from users. One project at Chemical Abstracts, which sells information services for chemists, has all members of the development team, including the project manager, rotate through the office that handles customer calls. This way everybody finds out what customers are trying to do, and what problems they encounter, first hand.

HyperTopic: Suggestions for User-Centered Phone-in Help

Speak the user's language. (Obviously!)


Be polite, cheerful, and positive. Don't be arrogant, and don't make users feel like the problems are their fault.


Give frequent feedback so the user knows that the conversation is going in the right direction. An example of phone interactions where this is typically done well is the practice of reading back order information for credit-card catalog orders.


If there's information that the user will have to provide, such as a software version or license number, make sure it's recorded where the user can find it. The start-up screen is a possibility, or under an "About this program" menu, with the information also recorded in the manual in case the system won't run.


Avoid asking for information that isn't related to the user's problem. Asking for the software license number is OK. Users will understand that only licensed software is supported. But it's wasting the user's time to ask where the package was purchased (corporate users often won't know), or what is the user's zip or area code.


Make it possible for the user to call back and get the same technician for follow-up help. After explaining the problem in detail to a disembodied voice named "Janet," the user doesn't want to call back 15 minutes later and be routed to "Carl," who not only doesn't know the problem but hasn't even heard of "Janet."


Transferring the user's call to other support people is always dangerous. Something that will help is a phone system that can support a brief three-way connection during which the technician eases the transition. Otherwise the user is put on the spot, having to explain the problem again, as well as explaining why they've been transferred.


For users, the worst-case scenario is one in which you can't transfer them at all and they have to redial, especially if they have to punch their way through a touch-tone dialog and come back into the end of a hold queue.



Copyright © 1993,1994 Lewis & Rieman
Contents | Foreword | ProcessUsers&Tasks | Design | Inspections | User-testing | Tools | Documentation |