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.)

Forward

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:

• the users the machine seems to be designed for;
• the tasks and subtasks the machine was evidently designed to support;
• the "interface" part of the machine;
• the part of the machine that is NOT the interface.

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:

• A backpacking checklist builder. People who only backpack once or twice a year may spend so much time deciding what to take, running from store to store to pick it up, and packing it, that the trip is more work than fun -- and something usually gets forgotten anyway. This software would produce simple pre-trip instructions and checklists that would alleviate these problems.
• A cooking help system for folks who don't cook often. Many single people cook only infrequently, so they don't have many ingredients on hand in the kitchen. When they do cook, planning and shopping is as much a part of their effort as following the recipe. This software would help the infrequent cook maintain a kitchen with the ingredients common to many meals, and would help plan meals that could be produced (or nearly so) with what was currently on hand.

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:

• a description of the users you interviewed;
• a description of the general characteristics of the system's users, based on your interviews;
• your understanding of the tasks and subtasks the interface will support;
• how your understanding evolved as the analysis proceeded.

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:

• They are intended to be used in text with minimal effort by users, especially novices.
• Their default indent and spacing is set automatically by the word processing program, which chooses these values to make the list look good with the preceding paragraph.
• The user can specify whether the items of the list are preceded by a special character (such as a bullet) or are sequentially numbered or lettered.

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:

• What is the underlying metaphor of the program, if any?
• Are there any other obvious metaphors that are used within the program?
• Where are some of the points the metaphors fail? That is, what behavior would the metaphors lead you to expect that isn't supported?
• Did the metaphors help you discover how the program works? Did they help you remember the functions of the controls?

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 BRIEF description of the system -- a sketch of an answering machine would supply most of the details, and you can include more information later in the walkthrough stories.
• The list of correct actions.
• A story for each action. It can be short, but it should touch on all four important points:
  • is the user trying to do the right thing?
  • is the correct action obviously available?
  • will the user connect the correct action to what they are trying to do?
  • after the correct action is performed, will feedback show it was the right thing to do?
• If there were problems, suggest how they could be fixed.

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:

• conceptual understanding of the interface (e.g., for a spreadsheet, the screen represents a grid of cells);
• low level details about how to enter text, select from menus, etc.;
• information about what commands are available, and where;
• expectations as to the interface's response to certain actions.

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:

• If you've never programmed, you might try out HyperCard or some similar "visual programming" system that can be programmed using menus and on-screen graphical objects.
• If you've programmed in traditional languages such as Pascal, C, or BASIC, then you might also try out a visual system. Make it a game to see how far you can push the language without falling back on traditional programming techniques. - If you're a nonprogrammer who's a regular user of
• preadsheets, you might try to learn your spreadsheet's macro programming language.
• If you're familiar with most of the programmable applications on your own system, learn how to use a programming environment in another system -- a Mac, or a PC, or even UNIX (budget more than 6 hours for this one!).

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:

• The control system will initially be marketed in cold- climate areas, so you should consider only heating functions, not air conditioning.
• Different heating methods (hot air, hot water, steam, electric) may have slightly different requirements. In a real design situation, you would discuss this issue with engineers. For the purposes of this project, act as your own engineering expert and consider only the kind of heating you have in your home.
• An important contribution to heating cost savings has been identified as "zoned" heating. For example, the bedrooms should be kept cool during the day when no one is using them, even if the kitchen or playroom is being heated during that period. Design the system to support three or more zones, and assume the method of heating will also support this.
• Your marketing and production departments have a rough idea of how much hardware you can afford to incorporate into the interface. It's assumed that you will need a simple microprocessor, ROM for program code, and nonvolatile RAM for storing settings. As a rough estimate, assume you have the processing power of a Macintosh or an IBM-PC.
• The physical interface is more limited than the underlying processor. Marketing has determined that homeowners don't want large, complex controls on their walls. You must incorporate the controls onto a 4-inch by 6-inch control panel. In this space you can put whatever you want: buttons, dials, gauges, lcd screens, touch screens, stylus pads, color, etc. Stay with hand-and-eye interactions; don't propose voice systems.
• Each zone can have its own control panel, or you can combine all controls on a single master panel. (Marketing votes for a single panel, because that's cheaper and easier to install.)
• Each zone has its own temperature sensor. The heating system will be able to maintain a set temperature for each zone. However, changes to temperature won't occur instantly.
• Some of the tasks that marketing thinks the control system should support are:
  • presetting temperatures that the heating system should maintain for zones at various times during various days of the week (for example, keep bedrooms at 50 degrees in the daytime, except Sunday before 10 a.m.);
  • overriding preset settings for a few hours (for someone at home on a single-day holiday);
  • overriding preset settings for a few days (when no one is at home during vacation).
  Your task and user analysis should confirm, deny, or expand on these.

F.2. Deliverables

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

• Sequence: The project is divided into three separate parts, each of which should be completed before the next is begun.
• Page limits: Each of the three parts should take about two or three pages. You may want to include sketches of your design that will take up additional space.
• Strategy: This interface will be used by nontechnical people, usually without any training. If your interface description covers ten pages, then it probably includes a lot of features that no one will ever discover or figure out. Try to keep the interface as SIMPLE as possible!

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.

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