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 |

0.1 What's This Book All About?
        0.1.1 Who Should Be Reading the Book?
        0.1.2 What Is the User Interface?
        0.1.3 What Kind of User Interfaces Does This Book Cover?
        0.1.4 Why Focus on Design?
0.2 How to Use This Book
        0.2.1 HyperTopics and Examples
        0.2.2 Exercises
0.3 About Shareware: How to Get and Pay for This Book
        0.3.1 Why Shareware?
        0.3.2 Special Note to Instructors and Students
        0.3.3 Where to Get Up-To-Date Copies
        0.3.4 Corrections and Additions
        0.3.5 Let Us Know What You Think
0.4 About the Authors
0.5 Acknowledgements
0.6 Disclaimers


0.2.2 Exercises


Readers who are seriously interested in becoming effective interface designers should work through the exercises for each chapter. A central goal of task-centered design is to reveal interface problems to the designers who create them, before the interface hits the street. But even with task- centered design, the ability to identify interface problems is a skill that can be improved with practice. The exercises are intended, in part, to give that practice.

Example: It's Obvious... Isn't It?

You may read our examples of problem interfaces and say to yourself, "Well, that's an obvious problem. No one would really design something like that. Certainly I wouldn't."


Here's a counter-example from the author's personal experience. John has a stereo system with a matched set of components made by the same manufacturer: a receiver, a CD player, and a cassette deck, stacked in that order. They all have the on/off button on the left side. Every time John goes to turn off all three components, he presses the top left button on the receiver, which turns it off; then he presses the top left button on the CD player, which turns it off; then, naturally, he presses the top left button on the cassette deck -- which pops open the cassette door. In retrospect, it seems "obvious" that the manufacturer could have improved the interface by putting all three buttons in the same location. But it clearly wasn't obvious to the system's designers, who (the advertisements tell us) were especially interested in building a system with a good user interface. We can guess that it wasn't obvious because the designers never considered the right task: the task of turning off all three components in sequence.


The flip side of the "it's obvious" coin is that most actions used to accomplish tasks with an interface are quite obvious to people who know them, including, of course, the software designer. But the actions are often not obvious to the first-time user. For example, imagine a first-time user of a multiuser computer who has been shown how to login to the system, has done some work, and is now finished with the computer for the day. Experienced computer users will find it obvious that a logout command is needed. But it may not occur to first-time users that a special action is required to end the session. People don't "log out" of typewriters or televisions or video games, so why should they log out of computers? Even users who suspect that something is required won't be likely to know that typing the word "logout" or "exit" might do the job.


Learning to predict problems like these by taking the user's point of view is a skill that requires practice, and that practice is a fundamental goal of the exercises.


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