*************************************************************
* *
* 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. *
* *
*************************************************************
* * * * * * * * * * * * * * * v.1
*
* 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.
[end example]-----------------------------------------------
----------------------------------------------------------
0.3 About Shareware: How to Get and Pay for This Book
----------------------------------------------------------
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.
0.3.1 Why Shareware?
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.
0.3.2 Special Note to Instructors and Students
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.
0.3.3 Where to Get Up-To-Date Copies
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.
0.3.4 Corrections and Additions
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.
0.3.5 Let Us Know What You Think
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.
----------------------
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 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.
---------------------
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.