Task-Centered User Interface Design : Foreword

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.

0.1 What's This Book All About?

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.

0.1.1 Who Should Be Reading the Book?

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.

0.1.2 What Is the User Interface?

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.

0.1.3 What Kind of User Interfaces Does This Book Cover?

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.

0.1.4 Why Focus on 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.

0.2 How to Use This Book

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.

0.2.1 HyperTopics and Examples

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.

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.

0.3 About Shareware: How to Get and Pay for This Book

Way back in 1993, or whenvever we started, we decided to make this book available as "shareware." That means we, the authors, retained the copyright to the book, but we allowed readers 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.

0.3.1 Why Shareware?

We chose shareware as a distribution method for several reasons. For one thing, we hoped it would make the book available to a wider audience, both because the cost was less ($5 + your printing/copying costs, as compared to probably $20 for a traditional book) and because anyone who couldn't afford the full cost was encouraged to pay just what they could afford -- or what they thought the book is worth. We've chose to make the book shareware rather than freeware because we we wanted some reimbursement for our development efforts.

We also hoped that this distribution method will save a few trees. We 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 liked 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 counted ourselves fortunate to have caught the leading edge of a technology that makes this kind of independent publishing possible.

0.3.2 How It All Worked Out

We're delighted to say that all this worked out as well or better than we hoped. We received payment from many appreciative readers, and clever in-kind contributions from others. People undertook to translate the book in Polish, that we know of, and maybe other languages. We have been well compensated, not only by the payments and gifts, but also by the kind words of appreciation many people sent. So we decided (some time ago, actually) not to accept further payment. It's taken us a while to update the book to say that!

So, thanks to all of our past readers, and best wishes to any future ones... use the book with our blessing. We also owe special thanks to Gary Perlman, for generously preparing the original text for Web publication, and arranging hosting.

By the way, a kind colleagues suggested to us some years ago that we publish the book with a conventional publisher. We found a publisher who was OK with out leaving the shareware version up online, a condition for us, and we pursued the idea. The publisher sent to ms out for review, and sent us a bunch of comments and suggestions for revision.

We got together to go through the reviews, and make revisions, but we found we both had the same reaction as we read the comments. We had written the book we wanted to write, and the reviewers wanted a different book. We both thought, "Let them write their own book!" So we abandoned that effort. We've been very happy with our self publishing experience, and we can recommend it to anyone!

0.4 About the Authors

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 earned his Ph.D. in computer science at the University of Colorado, where he investigated 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. He went on to a career with Nokia, in the USA and Finland, and he is now back in Boulder, retired.

Both authors have taught courses in user interface design using draft versions of portions of this book.

0.5 Acknowledgements

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

0.6 Disclaimers

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.