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.
skip navigation Contents | Foreword | Process | Users&Tasks | Design | Inspections | User-testing | Tools | Documentation | Legal | Managing | Exercises


These exercises will give you some experience in the steps that make up task-centered design. Each exercise includes a page limit for the report of your findings. That limit should force you to think about what you've found and report just the most important facts, instead of an endless list of points with no distinction as to importance. (A "1-page" limit is about 500 words.)


Exercise 0.1. Looking for the Interface

In your home or workplace find a simple machine, something with two to four controls and with no (!) internal computer (a simple toaster or an electric drill are possible candidates). Describe:

Limit your answer to one page (it may be less).

Chapter 1. Task-Centered Design.

Exercise 1.1. Task-Centered Design in Other Areas

We present the task-centered design process as an approach to producing better computer interfaces. A similar process could be used for any other field that produces artifacts (i.e., man-made things) for people to use in accomplishing tasks. Some examples are books, buildings, hand tools, and cookware. Where have you used parts of the task-centered design process in your own life or work? (If nowhere, then where could you have used them productively?)

Be specific about which steps in the task-centered design process you did or did not use.

Limit your answer to one page.

Chapter 2. Getting to Know Users and Their Tasks.

Exercise 2.1. Task and User Analysis

This exercise involves working with other people, so you should get started on it right away, so you'll have time to schedule meetings.

Here are two potential software products:

Pick just one of these projects. IT SHOULD BE THE ONE YOU KNOW THE LEAST ABOUT! Find someone who fits the general description of the user (backpacker or infrequent cook) and spend an hour or so with them doing a task analysis. Then think about those results for a while and produce a rough description of the system's functions and interface. Find another (different) potential user and discuss the system you've described.

Focus your work on tasks and users, and don't get hung up on detailed or difficult details. For example, each of the projects could require large amounts of stored and frequently updated data; identify the need to store and update that data, but don't worry about exactly how it will be loaded into the computer.

Write a report describing what you've learned. The report should focus on tasks and users; it should not be a description of the system. It should include at least the following:

Your answer should take about two pages.

Chapter 3. Creating the Initial Design

Exercise 3.1. Selecting Controls

Imagine that you are working for the software developer of the word processor you use most of the time. After surveying users' needs, the developer has decided to add a new feature: "QuickLists." QuickLists (which might look like the following list) have the following characteristics:

Where should the program incorporate the commands to apply this new feature and set the character that precedes each list item? On a menu? On the keyboard? In dialog boxes? Somewhere else? Give reasons for your answer.

(If your word processor already has a feature like QuickLists, then answer the same question for the following new feature: A company style checker, which checks memos, reports, and letters to make sure they follow the official company guidelines for format, spelling, and style. Assume that guidelines are predefined by the support staff at the user's company, so all the user has to do is specify whether the document being checked is a memo, report, or letter.)

Your answer should take about one page.

Exercise 3.2. Borrowed Colors

Find an interface that uses color. It can be on a computer or somewhere else (a stereo system, car, or appliance, for example). List at least three of the colors, note what they're used on, and explain how that use of color relies on ideas borrowed from other interfaces. For example, you might look at the dashboard of a car and comment: "low-oil warning, red; red is the color for stop lights, and you should stop your engine if the oil is low."

Try to find at least one use of color that is both supported and contradicted by established use, and explain why the designers might have chosen that color.

This assignment should take one page or less.

Exercise 3.3. Unpacking a Metaphor

In the "good old days" (see HyperTopic), many systems were designed using explicit metaphors -- that is, new things on the computer were represented by things that users were expected to already know. A well-known example is the Macintosh "desktop" metaphor, which uses icons that look like sheets of paper to represent computer files, icons that look like paper folders to represent computer directories, and an icon that looks like a trash can to represent the delete operation.

We don't advise you to create new metaphors, but it may be useful to understand existing metaphors and their value when you create new applications in an existing environment. This exercise should get you to think about how metaphors work.

Locate a system or software package that's very different from those you're familiar with. If you are primarily a PC user, you might see if someone will let you use a Macintosh for a while. If you've never used a "paint" or "draw" program, you might borrow one of those, or try one at a computer software store. If you have broad experience with many systems, you might try to locate a public-domain game that you've never played.

Explore the software for a while, using whatever method and resources you find most effective. Then analyze the program in terms of metaphor:

Limit your answer to two pages.

Chapter 4. Evaluating the Design Without Users

Exercise 4.1. Cognitive Walkthrough

Perform a cognitive walkthrough for the following situation:

System: The telephone answering machine or messaging system you have at home or at work.

Users: First-time users of the system, without training and without a manual. (If the system isn't on a separate machine, assume the user has the minimal documentation -- maybe a template on the touch-tone pad, or a wallet card summarizing key commands.)

Task: Check for messages, find there are some (five), play them, replay the second one, and then delete all of them.

Note that "delete all five messages" may have different meanings depending on the system you are using. For some systems, it may mean positioning the cassette tape so the next messages will overwrite the old ones. Other systems might not require any action -- maybe new messages automatically overwrite old ones, or maybe old ones aren't saved unless a special command is issued. In any case, assume your user wants to "delete" the messages because that's what he or she has always done with other answering machines.

What to write up:

A note on strategy: Like the designer of a system, you are probably intimately familiar with this task on your own phone answering system. Try to use the walkthrough procedure to distance yourself from that familiarity.

This assignment may take two to four pages.

Exercise 4.2. Action Analysis for Knowledge Assessment

One possible outcome of an action analysis is a list of things the user needs to know in order to use an interface. (Notice the "remember" items in the back-of-the-envelope analysis of taking pictures with a 35-mm camera.)

Consider the word processor you are most familiar with. Do a back-of-the-envelope action analysis for entering a document of several paragraphs using that system. Assume a less-than- perfect typist, so corrections will have to be made. Use the analysis to identify the knowledge needed to perform the task. The knowledge may include:

A complete listing of the knowledge would take more time than you need to spend on this assignment, so organize your answer by major areas of knowledge and give full details only for representative items.

Your answer should provide about one page for the action analysis and another page for the knowledge list.

Exercise 4.3. Heuristic Analysis

Locate an on-line library catalog, either at a university or at your local public library. Use Nielsen and Molich's heuristics to evaluate the interface.

Get together with three or four other students and combine your analyses into a single list of problems with the interface. Assign priorities to the problems, so the designers of the system would be able to decide which things were most important to change.

Your answer should take a page or two, depending on the quality of the interface.

If you want to do more: Do a quick cognitive walkthrough of the same interface, using what you believe to be a representative task. In a half page or less, compare the kinds of things discovered by heuristic analysis to the kinds of things discovered by the walkthrough.

Chapter 5. Testing the Design With Users

Exercise 5.1. Thinking Aloud

Ask two friends to be subjects of thinking-aloud studies. Choose a simple piece of software that your subjects have never used (a word processor, spreadsheet, or graphics program would be good). Take an hour or so to work with the program and devise a task that an experienced user could complete in about five minutes. Your novice users will probably require half an hour or more for the same task. Decide on "fallback" procedures -- when will you give the subjects help and what will you say if they are seriously stuck.

Follow the thinking-aloud instructions given in Chapter 5, taking special care to emphasize that you are testing the interface, not the subjects' abilities. Review the HyperTopic on "Ethical Concerns" before you begin.

Record each subject's behavior on video if possible, or on audio tape. Remember that it may sometimes be necessary to remind a subject to think aloud.

Analyze the tapes to discover problems with the interface. Your report should not exceed three pages. For each problem, consider whether it might occur with other users (why or why not?) and how it might be solved. Note any additional problems that your subjects did not have, but that occurred to you during the study. Comment briefly on the differences between the two subjects.

Exercise 5.2. Failures of User Testing

Think of a sophisticated program that you use regularly, a program that comes with a slick manual and has clearly been designed for usability -- perhaps your default word processor or spreadsheet program. Identify the interface bug in that program that you find most annoying. Since you are a user and you have this problem, user testing should have identified it -- isn't that right? So, why is the problem still there?

A half page should be enough to answer this.

Chapter 6. User Interface Management and Prototyping Systems

Exercise 6.1. Learning About Your System

This is an assignment that you will have to help define on your own: Find out what UIMS/prototyping systems are currently available for "your" system. "Your" system may be the networked computer system you use as a programmer, or the system used by the programmers you work with, or the personal computer you use at home or school.

This isn't an assignment you can do entirely on your own. You should talk to other people who are using the same system. Ask them what they use and how satisfied they are. Look in trade magazines for that system. Check out software stores and ads.

As you investigate what's available, keep in mind that deciding what to use should be a task-centered process. A software package that's good for the task of prototyping small applications may not be adequate for final development of large applications.

Write one to two pages listing the foremost packages with their strengths and weaknesses. Identify the sources of your opinions.

Exercise 6.2. Pushing the Envelope

This is another assignment that you have to define on your own. The general idea is to push your programming abilities beyond where they are today. But it's also important to push them in the right direction.

Here's what you should do. Identify a UIMS or prototyping system that you have never used. Then spend 3-6 hours (we'd suggest two morning or evening sessions) learning the basics of using it. When you're done, you should have created at least one "program."

Here are some examples of systems you might learn:

Whatever your level, there are two cautionary points:

  1. Don't waste your time by trying to get started on this project alone. Ask for help from someone who's more advanced. Just be sure that, when you're done, you can create a program on your own.
  2. The goal of this exercise is to give you experience in "smarter" programming, not just more programming. Do something more than demonstrating the skills you already have, no matter how good they are.

Write a page describing what you did.

Chapter 7. The Extended Interface

7.1 A Mini-Manual

Choose a single, simple task that can be accomplished with a program you know. Writing a two-line memo with a word processor is an example, or entering a trip report on a spreadsheet, or drawing a party invitation in a paint program. Write the parts of a manual that would support your task, including (1) the detailed task instructions, (2) the command reference, and (3) the super index.

Note that this isn't the complete manual -- it's just the excerpt necessary for a specific task. But you should keep the needs of the full manual in mind as you work. The length of the manual will depend on what you need to put into it.

After you've finished -- and only then -- compare what you've written to the program's manual. Write a page describing the differences and saying which way is best.

7.2. Help!

Find a program that has on-line help. Consider the help system from a task-centered point of view. How would you improve the system, if at all? Write no more than a page.

Final Project

This project gives you a chance to use most of the design and evaluation techniques described in the book. It should take several weeks to complete.

F.1. The Design Assignment

Imagine that you have been asked to design the user interface to a "smart" home thermostat. The system will be targeted at middle-income home owners, for both new and existing homes. The marketing strategy will be to emphasize the cost-savings and environmental benefits of presetting the system to keep rooms warm only when they are likely to be in use. A preliminary market survey has shown that homeowners are receptive to this idea, and a number of competing systems are already on the market. However, the marketing survey has also shown that existing systems are typically too complex and confusing for the homeowner to use effectively. The key to your system's success, therefore, will be its excellent user interface.

Here are the major requirements and constraints of the design:

F.2. Deliverables

Here's exactly what you should do and what you need to write up.

Attention Programmers! This is a DESIGN task. You should be able to do the entire project without writing a line of code. If you decide to implement a prototype, be sure you can explain why that was a better use of your time than doing further user testing with mockups.

Assignment 1. Task and User Analysis

You will probably consider yourself a potential user of this system, but it's always dangerous to rely on your own impressions. So you should interview at least two possible users, from different households, and write up the following:

  1. A description of the users you interviewed.
  2. The general characteristics you expect system users to have (age, education, etc.).
  3. A description of five scenarios of system usage. For example, "The homeowner gets up at 3 a.m. with a sick child and decides to sit with the child in the living room. The living room is cold, and the homeowner wants to bring it quickly to an above-average temperature." These scenarios will be used in your task-centered design efforts. They should be chosen to cover the most important functionality of the interface.
  4. A list of the basic tasks the system will support. This is a "sanity check" to make sure your task scenarios haven't left out anything critical.

Assignment 2. Initial Design and Cognitive Walkthrough

Produce an initial description of the interface and perform cognitive walkthroughs on it using three of the tasks you identified for task-centered design. Write up:

  1. a description of your initial interface design.
  2. a description of any problems discovered with the walkthroughs.
Assignment 3. Thinking-Aloud Study and Final Design

Modify your design to correct the problems discovered by the cognitive walkthroughs. Then do thinking-aloud studies with two potential users. Ask each user to accomplish one (or more, if you have time) of the tasks defined in the scenarios for task-centered design.

For example, you would first describe the "thinking-aloud" process to your subject, and emphasize that you are testing your interface, not their ability. Then, if you were using the scenario described above, you would present your user with a drawing or cardboard mock-up of your design and say: "Imagine yourself getting up at 3 a.m. with a sick child. You decide to sit with the child in the living room. But the living room is cold, so you want to bring the temperature quickly up to 75 degrees. Show me what you would do using this heat control system, and please let me know what you're thinking as you work through the problem."

Revise your design to avoid any problems discovered in the thinking-aloud studies. Write up:

  1. A brief description of the thinking-aloud studies, with special attention to any problems they discovered.
  2. A description of your final interface design.
  3. The "design rationale" -- that is, your reasons for the important features of your design. The reasons should generally refer to the scenarios you've used in task-centered design.

Copyright © 1993,1994 Lewis & Rieman
skip navigation Contents | Foreword | Process | Users&Tasks | Design | Inspections | User-testing | Tools | Documentation | Legal | Managing | Exercises | Top