Task-Centered User Interface Design
A Practical Introduction
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
In this introductory material we explain the book's goals and introduce some basic terminology. In particular, this book is about the design of user interfaces, and it's useful to discuss what we mean by "user interfaces" and why we have decided to focus on the process of their "design."
We also tell you a little about the authors, we acknowledge some people and organizations that have helped with the book, and we tell you about the shareware concept under which the book is distributed.
The central goal of this book is to teach the reader how to design user interfaces that will enable people to learn computer systems quickly and use them effectively, efficiently, and comfortably. The interface issues addressed are primarily cognitive, that is, having to do with mental activities such as perception, memory, learning, and problem solving. Physical ergonomic issues such as keyboard height or display contrast are covered only briefly.
We've designed this book to be most useful for people who are actually developing user interfaces. That's in contrast to the full-time interface professionals who do research and evaluation in large corporations. We strongly believe that effective interactive systems require a commitment and an understanding throughout the entire development process. It just won't work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter.
With that in mind, some of the people who should be interested in this book are programmers, systems analysts, users and user-group representatives, technical writers, training coordinators, customer representatives, and managers at several levels. All of these positions have input into how the final system will look and act.
The basic user interface is usually understood to include things like menus, windows, the keyboard, the mouse, the "beeps" and other sounds the computer makes, and in general, all the information channels that allow the user and the computer to communicate.
Of course, using a modern computer system also involves reading manuals, calling help lines, attending training classes, asking questions of colleagues, and trying to puzzle out how software operates. A successful computer system or software package supports those activities, so that support is part of the user interface too.
But in a sense, all of these parts are the "peanut butter" we mentioned in the previous section. No matter how well they are crafted, the interface will be a failure if the underlying system doesn't do what the user needs, in a way that the user finds appropriate. In other words, the system has to match the users' tasks. That's why the book's central message is the need for "task-centered" design, and that's why the design of the user interface can't be separated from the design of the rest of the system.
The principles presented in this book were developed primarily in the context of the interfaces to computer software and hardware, but they are also applicable to a wide variety of other machines, from complex equipment such as phone systems and video cameras to simple appliances like refrigerators and power tools. Simpler machines are sometimes informative examples of problems or solutions in interface design.
This book describes design processes that help to produce good interfaces. The focus on process instead of end result deserves some explanation. Why don't we simply describe what a good interface is and leave the reader to create interfaces that fit that description?
There are several reasons. An interface has to be matched to the task it will support, as well as to the users who will work with it. There is an infinite variety of tasks and users, so there's no simple definition of a "good" interface. There have been many attempts to give broad, general guidelines for good interfaces, but those guidelines are usually too vague to be of much use. For example, a general guideline might say, "Give adequate feedback." But how will the designer determine what's "adequate"?
More specific guidelines for elements of the final interface have also been developed, describing such elements as how menus should be designed, how to label icons, and so forth. These guidelines also have problems. It's impossible to cover every possible combination of task, user, and interface technology, so no set of specific guidelines can be complete. Even so, lists of specific guidelines are often so large and cumbersome that practicing designers find them very difficult to use. Further, in a given situation there are often several contradictory guidelines, and the designer has to rely on intuition to decide which are most important.
We might make an analogy between a designing a successful interface and a cutting a piece of string to the "right" length. General guidelines for the length of a piece of string, such as "long enough to do the job," aren't very helpful; and a list of specific definitions of the correct length for every purpose would be endless: 6 inches to tie up sagging flowers, 42 inches for a small package, 78 inches to tie down the trunk on an old VW, etc. But it's easy to describe a process that produces the right length: start with a very long piece of string, tie up your plant, package, car, or whatever, and then cut off the string that's not being used. Similarly, instead of specifying all the characteristics of the finished interface, this book present a design process that can produce good interfaces.
This is not to say that simply following the design process will magically produce a successful interface every time. The designer using the process must make many decisions along the way, relying on knowledge of users, their cognitive skills and limitations, and their tasks. In addition, the interface design process will only be successful if it is integrated into the software production process as a whole. This book presents basic information about all of these issues, and it contains pointers to other books and articles containing further useful information. All this material is organized in the context of the design process.
The main body of this book is a series of chapters describing in rough chronological order the steps needed to design a good user interface. Chapter 1 provides an overview of this process, and Chapters 2 through 7 fill in the details. Two appendices provide additional information on topics that don't fit into this chronological structure and that may not be of interest to every reader. Appendix L provides guidance on legal issues in interface design, while Appendix M gives an overview of management concerns.
This book has been designed to achieve some of the advantages while avoiding some of the problems of computer-based hypertext. Hypertext has the advantage of providing pointers within the text that lead readers to additional material on topics that interest them. For example, a paragraph about typewriters might contain the word "keyboard," and clicking that word with a mouse could cause the computer to display a paragraph about different keyboard layouts. We've incorporated a similar technique by placing examples and supplemental material called "HyperTopics" near the text they're related to.
Hypertext has the disadvantage that readers often become confused as they jump from the middle of one concept to another, and to another, and to another, loosing track of any central theme. This book provides a mainline, the plain text you are reading now, that ties together all the details under the common theme of the design process. Chapters in the book are ordered to reflect that process, although materials within each chapter are often organized according to more abstract principles. For a quick overview or review of a chapter, you may want to read just the chapter's mainline.
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.
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.
We've decided to make this book available as "shareware." That means we, the authors, have retained the copyright to the book, but we allow you to copy it and to make your own decision about how much it is worth. The details on copying restrictions and payment are included in a box at the end of every chapter, including this one.
We've chosen shareware as a distribution method for several reasons. For one thing, we hope it will make the book available to a wider audience, both because the cost is less ($5 + your printing/copying costs, as compared to probably $20 for a traditional book) and because anyone who can't afford the full cost is encouraged to pay just what they can afford -- or what they think the book is worth. We've chosen to make the book shareware rather than freeware because we we would like some reimbursement for our development efforts.
We also hope that this distribution method will save a few trees. We've intentionally removed all sophisticated formatting so the text can be used on-line as a reference with virtually any computer system. You also have the option of printing just the chapters you need.
Finally, we like the idea of distributing our ideas directly to the "end-user" without the filter of a publisher. It's not that we think commercially published books are bad; but there's clearly room in the world for books that are published by individuals, just as there's room for handmade pottery, independent computer consultants, roving jugglers, and freelance carpenters. We count ourselves fortunate to have caught the leading edge of a technology that makes this kind of independent publishing possible.
Instructors who want to use this book for class have our permission to make and sell copies to students for the price of copying, or to have the copies made and sold through a commercial copy service, or to make an original available to students so they can make their own copies. Please be sure to include the shareware notice from the front of the book in every copy (including copies of individual chapters). Students are asked to send in the shareware fee if they decide the book is useful to them.
To get a current copy of the electronic version of this book, use ftp to connect to "ftp.cs.colorado.edu" (yes, "ftp" is part of the address). For login name, type "anonymous"; for password, give your full login name. Look for the files in the directory /pub/cs/distribs/clewis/HCI-Design-Book.
You can help us, and your fellow readers, by letting us know when our presentation is wrong or incomplete. We'll do our best to incorporate improvements into future versions.
If you send in a shareware payment (or even if you don't!) we'd like to have your comments and suggestions. What parts of the book are especially valuable to you? What else would you like to see included? We probably won't be able to answer specific questions or reply personally to your letters, but we'll consider your comments if the book is a success and we decide to do a major revision.
Clayton Lewis is Professor of Computer Science and a member of the Institute of Cognitive Science at the University of Colorado. Before coming to Colorado he worked as a programmer, researcher, and manager of user interface development in corporate settings in the United States and England. He has continued to maintain close contacts with industry. Clayton holds a Ph.D. in psychology from the University of Michigan. His current research involves theoretical analysis of learning processes, assessment and design of programming languages, and development of prototyping tools.
John Rieman is finishing a Ph.D. in computer science at the University of Colorado, where he is investigating users' techniques for learning new interfaces in the absence of formal training, His interest in user interfaces developed during 10 years "in the trenches" as a user and manager of computerized editorial and typesetting systems. John's varied background also includes studies in art, mathematics, and law, as well as work experience as an auto mechanic and truck driver.
Both authors have taught courses in user interface design using draft versions of portions of this book.
This book is a practically oriented distillation of ideas that have grown out of many years of productive collaboration, formal and informal, with individuals in both the academic and the industrial human-computer interaction (HCI) community. We have attributed ideas to individuals wherever possible, but we acknowledge a debt to many unnamed persons whose efforts have combined to provide a deeper understanding of the problems and solutions in the field.
We especially acknowledge the contribution of two of our colleagues at the University of Colorado, Peter Polson and Gerhard Fischer. Their research, as well as their insightful counter-arguments to points we might otherwise have accepted as obvious, make CU an exciting and productive environment in which to do HCI research.
Clayton also wants to acknowledge his debt to John Gould, recently retired from IBM Research. John has given Clayton help, guidance, and friendship, as well as his keen insights into all kinds of issues, technical and nontechnical, since 1970.
Many people, including our students, contributed suggestions that have helped to make this revised edition of the book a better publication. In particular, we acknowledge the detailed comments of Dieter Boecker of the GMD and John Patterson of SunSoft.
Much of the research described here has been supported by the National Science Foundation (grants IRI 8722792 and 9116640), by US West, and by CU's Center for Advanced Decision Support in Water and Environmental Systems (CADSWES).
The opinions, findings, conclusions, and recommendations expressed in this publication are those of the authors and do not necessarily reflect the views of the agencies named in the acknowledgments section.
Comments about interfaces used as examples should not be taken as an evaluation of the interfaces as a whole. Every interface has its good and its bad points, and we have simply chosen problems that illustrate our topics.
Wherever trademarks have been used in this book they have been capitalized, to the best of our knowledge.
|Copyright © 1993,1994 Lewis & Rieman|