Task Analysis: Discovering What the Customer Needs

Home/Publications/Best Practices Newsletter/2001 – Best Practices Newsletter/Task Analysis: Discovering What the Customer Needs


February 2001

Task Analysis: Discovering What the Customer Needs

CIDMIconNewsletter Linda Siemers, Publications Manager, Compaq Computer Corporation

One of our goals this year has been to increase our understanding of whether our documentation adequately supports the installation of our file servers. As you know, when you solicit customer feedback, you can receive a stack of customer questionnaires that say “Excellent” and “No problems.” However, when you observe someone using the product, you see a different picture indeed.

We decided to determine our customers’ needs by using task analysis as our survey tool. Task analysis consists of observing the customer using a product to understand the major tasks the customer performs when he or she installs and operates the product.

For example, if you are planning to write an automobile user’s manual, you might decide beforehand that you need to describe how the brakes and transmission work. But when you observe the customer actually using the car, you find out that the customer has to know very little about these topics to operate the car. Instead, you may find that the customer is concerned chiefly with changing the oil and setting the clock.

Generally speaking, task analysis can be divided into the following eight stages:

  • Training
  • Building a Team
  • Defining Goals
  • Selecting a Customer
  • Planning the Analysis
  • Visiting the Customer
  • Reporting the Results
  • Implementing the Recommendations

Stage 1: Training

Before proceeding, we needed to know the following:

  • How to set analysis goals
  • How to interest a customer in our visit
  • How long we should stay at the customer’s job site
  • Who should perform the task analysis
  • Whether to videotape the visit
  • How to choose a task
  • Whether we could interrupt the person doing the task

We couldn’t find an article or a book that gives a step-by-step account of how to do a task analysis. Instead, we arranged for a two-day training session on how to conduct one. After the training, we felt prepared to begin the analysis.

Stage 2: Building a Team

Our next step was to identify a task analysis team from among those who attended the training session. We chose a technical writer (me), a marketing specialist with a background in technical communication and operating systems integration, and a human factors engineer (or ergonomics engineer) who could help us identify which product design features could be modified to make the product easier to use.

The team could have included a hardware and/or software engineer or a customer support engineer, all of whom would be knowledgeable about how the product works. As we discovered, three people can handle the logistics of a task analysis (moderator, videotape recording, and note taker).

Stage 3: Defining Goals

The team decided that the goal of the analysis was to find out whether our documentation supports an easy setup of a file server. We chose this goal because we could perform the observation in less than a day and because we know that the setup of a file server is an important and common task. Moreover, we thought it crucial that the setup function be well supported with easy-to-use and appropriate documentation because the ease or difficulty of the product setup often determines how a customer feels about the product.

After setting this goal, we decided who would play which role during the visit. We each chose roles appropriate to our skills. For example, because the human factors engineer often films people testing products in her lab, she was selected to do the videotaping.

Stage 4: Selecting a Customer

We picked a typical customer: a large corporation with several file servers, whose administrators are experienced with our products. (We hope to visit other customers with different profiles.)

You may feel at a loss to how to find a customer to visit. In this case, we were able to arrange the visit through the Field Support Engineering group. The Sales group might also help you to find a customer to visit.

Good public relations should be a part of the visit. We wanted to do everything we could do to make them feel good about our company. We bought some company coffee cups to give away. We also made plans to buy them lunch and to carry in some pastries for breakfast the second day. After we completed the visit, we wrote them a thank-you note and sent them information that they needed.

Stage 5: Planning the Analysis

Our next step was to determine how we would observe the customer installing the file server during the customer visit. Here is the schedule:

Day 1
Observe and videotape the customer setting up the server. (The human factors engineer suggested that we interrupt the customer as little as possible to maintain the normal flow of events. We asked the customer only a few questions during the first day.)

Day 2
Interview the file server administrators as a group.

We faxed the customer our questions before the visit so that he or she would feel more comfortable during the visit. The customer had some last-minute qualms about being videotaped, but we were able to quell the customer’s anxiety about the process. We stressed that the videotape session tests the quality of our products, not the customer’s abilities, and that a videotape is more convincing and entertaining than a written report.

We designed our questionnaire to address the actual task: Can the customer install the file server? Examples of our task-oriented questions include the following:

  • Have you had any problems setting up the file servers?
  • Is there any information you keep looking for and can’t find?
  • How do you learn to set up the server?
  • Do you ever call our Customer Support hotline?
  • What are you calling about?

We then proceeded with more typical questions addressing the documentation itself:

  • Where do you store the documentation?
  • Who uses the documentation?
  • Do you ever refer to the documentation?
  • Under what circumstances?
  • What is your preferred media-print or on-line?

Stage 6: Visiting the Customer

The most important information we learned is that the customer works in an incredibly hectic and stressful environment. We learned that the customer would benefit greatly if he or she received information on how the product works long before he or she receives the product. It’s almost too late to teach something new or different after the product arrives.

We learned how difficult it is to reach the customer with product information. If information isn’t a part of the process or a part of the product in some way, it’s rather unlikely that the customer will even see a piece of documentation, let alone actually read it. This hasn’t made us quit supplying printed documentation. It’s just made us realize we’re going to have to think harder and plan better.

Stage 7: Reporting the Results

After returning to the office, we immediately prepared an electronic mail message summarizing the major findings and transmitted it. Electronic mail seems to be much more effective than waiting to send out a complete report. We then sent an initial report to interested parties in engineering, marketing, technical communication, and customer support. The report contained the goals of the visit and major findings with recommendations. A few weeks later, we compiled a more complete report and scheduled meetings to show the videotape (with free popcorn!).

Stage 8: Implementing the Recommendations

We expected to find examples where the information structure for this product wasn’t providing sufficient support. We did find instances where the typeface was too small, where explanatory notes were needed, and where the system didn’t work the way the customer thought it should. We were surprised to find that the customer expects us to provide more information about all our products, not just the purchased product. We were also surprised by the customer’s preference for printed documentation, instead of on-line documents, for some types of information.

We can now work towards addressing these needs in our new products.

Even if you do only two or three task analyses per year, you will learn enough about how your customers do their work to make major changes to your documentation plans and to system features. Good luck! CIDMIconNewsletter

1. In 1993, there was no such book. Now you can find step information in User and Task Analysis for Interface Design by JoAnn T. Hackos and Janice C. Redish and in Contextual Design: A Customer-Centered Approach to Systems Design by Hugh Beyer and Karen Holtzblatt. (See the sidebar on the next page for reference information.)

2. JoAnn Hackos (Comtech Services, 303-232-7586) conducted the training session.