*            TASK-CENTERED USER INTERFACE DESIGN            *
*                                                           *
*                 A Practical Introduction                  *
*                                                           *
*                                                           *
*                       Clayton Lewis                       *
*                        John Rieman                        *
*                                                           *
*************************************************************



 -------------------------------------------------------- 
| SHAREWARE NOTICE:                                      |
|                                                        |
| The suggested shareware fee for this book is $5.00,    |
| payable to Clayton Lewis and John Rieman. Send it to:  |
|                                                        |
|       Clayton Lewis and John Rieman                    |
|       P.O.Box 1543                                     |
|       Boulder, CO 80306 USA.                           |
|                                                        |
| If sending U.S. dollars is difficult, for example if   |
| you aren't in the U.S., send us something else you     |
| think we'd like to have. Or send us two somethings,    |
| one for each of us.                                    |
|                                                        |
| COPYRIGHT INFORMATION                                  |
|                                                        |
| This book is copyright 1993, 1994 by Clayton Lewis and |
| John Rieman. You are free to make and distribute       |
| copies of the book in electronic or paper form, with   |
| the following restrictions: (1) We ask that you pay    |
| the shareware fee if you find the book useful and if   |
| you can afford it.  (2) Every copy must include this   |
| "shareware notice." (3) Copies must be unchanged from  |
| the original. (4) No part of the book may be sold or   |
| included as part of a package for sale without the     |
| authors' written permission.                           |
|                                                        |
| Original files for the book are available via          |
| anonymous ftp from ftp.cs.colorado.edu.                |
|                                                        |
| We thank you for your support!                         |
|                                                        |
 --------------------------------------------------------



* * * * * * * * * * * * * * * * * * * * * * * * * * * *  v.1
*                                                           
*                    Table of Contents     
*
*


Foreword


Chapter 1.  Task-Centered Design

Chapter 2.  Getting to Know Users and Their Tasks

Chapter 3.  Creating the Initial Design

Chapter 4.  Evaluating the Design Without Users

Chapter 5.  Testing the Design With Users

Chapter 6.  User Interface Management and Prototyping Systems

Chapter 7.  The Extended Interface


Appendix L. What Can You Borrow?

Appendix M. Managing User Interface Development

Exercises

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

----------
*   Chapter 1
*
*   The Task-Centered Design Process
*
*

This chapter gives an overview of the task-centered design 
process that the book recommends.  The process is structured 
around specific tasks that the user will want to accomplish 
with the system being developed.  These tasks are chosen 
early in the design effort, then used to raise issues about 
the design, to aid in making design decisions, and to 
evaluate the design as it is developed.  The steps in the 
task-centered design process are as follows:

	- figure out who's going to use the system to do what
	- choose representative tasks for task-centered design
	- plagiarize
	- rough out a design
	- think about it
	- create a mock-up or prototype
	- test it with users
	- iterate
	- build it
	- track it
	- change it

--------------------------------------------------------
1.1  Figure Out Who's Going to Use the System to Do What
--------------------------------------------------------

The industry terminology for this step is "task and user 
analysis."  The need for the task analysis should be obvious:  
if you build an otherwise great system that doesn't do what's 
needed, it will probably be a failure.  But beyond simply 
"doing what's needed," a successful system has to merge 
smoothly into the user's existing world and work.  It should 
request information in the order that the user is likely to 
receive it; it should make it easy to correct data that's 
often entered incorrectly; its hardware should fit in the 
space that users have available and look like it belongs 
there.  These and a multitude of other interface 
considerations are often lost in traditional requirements 
analysis, but they can be uncovered when the designer takes 
time to look into the details of tasks that users actually 
perform.    

Understanding of the users themselves is equally important.  
An awareness of the users' background knowledge will help the 
designer answer questions such as what names to use for menu 
items, what to include in training packages and help files, 
and even what features the system should provide.   A system 
designed for Macintosh users, for example, should provide the 
generic Mac features that the users have come to expect.  
This might mean including a feature like cut and paste even 
though cut and paste plays no important part in the system's 
main functionality.  Less quantifiable differences in users, 
such as their confidence, their interest in learning new 
systems, or their commitment to the design's success, can 
affect decisions such as how much feedback to provide or when 
to use keyboard commands instead of on-screen menus. 

Effective task and user analysis requires close personal 
contact between members of the design team and the people who 
will actually be using the system.  Both ends of this link 
can be difficult to achieve.  Designers may have to make a 
strong case to their managers before they are allowed to do 
on-site analysis, and managers of users may want to be the 
sole specifiers of the systems they are funding.  It's 
certain, however, that early and continued contact between 
designers and users is essential for a good design. 


--------------------------------------------------------
1.2 Choose Representative Tasks for Task-Centered Design
--------------------------------------------------------

After establishing a good understanding of the users and 
their tasks, a more traditional design process might abstract 
away from these facts and produce a general specification of 
the system and its user interface.  The task-centered design 
process takes a more concrete approach.  The designer should 
identify several representative tasks that the system will be 
used to accomplish.  These should be tasks that users have 
actually described to the designers.  The tasks can initially 
be referenced in a few words, but because they are real 
tasks, they can later be expanded to any level of detail 
needed to answer design questions or analyze a proposed 
interface.  Here are a few examples:

 - for a word processor:  "transcribe a memo and send it
   to a mailing list"
 - for a spreadsheet: "produce a salary budget for next
   year"
 - for a communications program: "login to the office
   via modem"
 - for an industrial control system: "hand over control
   to next shift"

Again, these should be real tasks that users have faced, and 
the design team should collect the materials needed to do 
them: a copy of the tape on which the memo is dictated, a 
list of salaries for the current year and factors to be 
considered in their revision, etc.  

The tasks selected should provide reasonably complete 
coverage of the functionality of the system, and the designer 
may want to make a checklist of functions and compare those 
to the tasks to ensure that coverage has been achieved.  
There should also be a mixture of simple and more complex 
tasks.  Simple tasks, such as "check the spelling of 
'ocassional'," will be useful for early design 
considerations, but many interface problems will only be 
revealed through complex tasks that represent extended real-
world interactions.  Producing an effective set of tasks will 
be a real test of the designer's understanding of the users 
and their work.  

--------------
1.3 Plagiarize
--------------

We don't mean plagiarize in the legal sense, of course.  But 
you should find existing interfaces that work for users and 
then build ideas from those interfaces into your systems as 
much as practically and legally possible.  This kind of 
copying can be effective both for high-level interaction 
paradigms and for low-level control/display decisions.

At the higher levels, think about representative tasks and 
the users who are doing them.  What programs are those users, 
or people in similar situations, using now?  If they're using 
a spreadsheet, then maybe your design should look like a 
spreadsheet.  If they're using an object-oriented graphics 
package, maybe your application should look like that.  You 
might be able to create a novel interaction paradigm that's 
better suited to your application, but the risk of failure is 
high.  An existing paradigm will be quicker and easier to 
implement because many of the design decisions  (i.e., how 
cut and paste will work) have already been made.  More 
important, it will be easy and comfortable for users to learn 
and use because they will already know how much of the 
interface operates.   

Copying existing paradigms is also effective for the low-
level details of an interface, such as button placement or 
menu names.  Here's an example.  You're writing a special-
purpose forms management package and the specifications call 
for a spelling checker.  You should look at the controls for 
spelling checkers in the word processing packages used by 
people who will use your system.  That's almost certainly how 
the controls for your spelling checker interface should work 
as well.

This is an area where it's really common for designers to 
make the wrong decision because they don't look far enough 
beyond the requirements of their own system.  Let's dig a 
little further into the example of a spelling checker for the 
forms package.  Maybe your analysis has shown that the 
spelling checker will most often pick up misspelled names, 
and you can automatically correct those names using a 
customer database.  So you decide the most efficient 
interaction would be to display the corrected name and let 
the user accept the correction by pressing the Return key.  
But the word processor your users use most frequently has a 
different convention: pressing Return retains the "wrong" 
spelling of a word.  Do you follow the lead of the existing 
system ("plagiarize"), or do you create your own, more 
efficient convention?  To an extent the answer depends on how 
often users will be running your system compared to how often 
they will be running systems they already know.  But more 
often than not, the best answer is to stick with what the 
users know, even if it does require an extra keystroke or 
two.

------------------------
1.4 Rough Out the Design
------------------------

The rough description of the design should be put on paper, 
which forces you to think about things.  But it shouldn't be 
programmed into a computer (yet), because the effort of 
programming, even with the simplest prototyping systems, 
commits the designer to too many decisions too early in the 
process.

At this stage, a design team will be having a lot of 
discussion about what features the system should include and 
how they should be presented to the user.  This discussion 
should be guided by the task-centered design approach.  If 
someone on the team proposes a new feature, another team 
member should ask which of the representative tasks it 
supports.  Features that don't support any of the tasks 
should generally be discarded, or the list of tasks should be 
modified to include a real task that exercises that feature. 

The representative tasks should also be used as a sort of 
checklist to make sure the system is complete.  If you can't 
work through each task with the current definition of the 
system, then the definition needs to be improved.  
 
------------------
1.5 Think About It
------------------

No aviation firm would design and build a new jet airliner 
without first doing an engineering analysis that predicted 
the plane's performance.  The cost of construction and the 
risk of failure are too high.  Similarly, the costs of 
building a complete user interface and testing it with enough 
users to reveal all its major problems are unacceptably high.  
Although interface design hasn't yet reached the level of 
sophistication of aircraft engineering, there are several 
structured approaches you can take to discover the strengths 
and weakness of an interface before building it. 

One method is to count keystrokes and mental operations 
(decisions) for the tasks the design is intended to support.  
This will allow you to estimate task times and identify tasks 
that take too many steps.  The procedures for this approach, 
called GOMS analysis, along with average times for things 
like decisions, keystrokes, mouse movements, etc. have been 
developed in considerable detail.  We'll summarize the method 
later in the book.

Another method is to use a technique called the cognitive 
walkthrough to spot places in the design where users might 
make mistakes.  Like GOMS modelling, the cognitive 
walkthrough analyzes users' interactions with the interface 
as they perform specific tasks.  We'll also explain how to do 
cognitive walkthroughs later in the book.  
 
---------------------------------
1.6 Create a Mock-Up or Prototype
---------------------------------

After thinking through the paper description of the design, 
it's time to build something more concrete that can be shown 
to users and that can act as a more detailed description for 
further work.  In the early stages of a simple design, this 
concrete product might be as simple as a series of paper 
sketches showing the interface while a user steps through one 
of the representative tasks.  A surprising amount of 
information can be gleaned by showing the paper mock-up to a 
few users.  The mock-up may even reveal hidden 
misunderstandings among members of the design team.

For further analysis, the design can be prototyped using a 
system such as HyperCard, Dan Bricklin's Demo Package, or any 
of an increasing number of similar prototyping tools.  It may 
even be possible to build a prototype using the User 
Interface Management System (UIMS) that will be the 
foundation of the final product.  This approach can be 
especially productive, not only because it reduces the amount 
of work needed to create the production system, but also 
because interface techniques tested in a stand-alone 
prototyping system may be difficult to duplicate in the 
production UIMS.  

The entire design doesn't need to be implemented at this 
stage.  Initial efforts should concentrate on parts of the 
interface needed for the representative tasks.  Underlying 
system functionality, which may still be under development, 
can be emulated using "Wizard of Oz" techniques.  That is, 
the designer or a colleague can perform the actions that the 
system can't, or the system can be preloaded with appropriate 
responses to actions that a user might take.  (The design 
team needs to take care that users and management aren't 
misled into thinking the underlying system is finished.)   

------------------------------
1.7 Test the Design With Users
------------------------------

No matter how much analysis has been done in designing an 
interface, experience has shown that there will be problems 
that only appear when the design is tested with users.  The 
testing should be done with people whose background knowledge 
and expectations approximate those of the system's real 
users.  The users should be asked to perform one or more of 
the representative tasks that the system has been designed to 
support.  They should be asked to "think aloud," a technique 
described in more detail in Chapter 5.

Videotape the tests, then analyze the videotapes for time to 
complete the task, actual errors, and problems or surprises 
that the user commented on even if they didn't lead to 
errors.  The user's thinking-aloud statements will provide 
important clues to why the errors were made.

-----------
1.8 Iterate
-----------

The testing with users will always show some problems with 
the design.  That's the purpose of testing: not to prove the 
interface, but to improve it.  The designer needs to look at 
the test results, balance the costs of correction against the 
severity of each problem, then revise the interface and test 
it again.  Severe problems may even require a re-examination 
of the tasks and users.

One thing to keep in mind during each iteration is that the 
features of an interface don't stand alone.  Revising a menu 
to resolve a problem that occurs with one task may create 
problems with other tasks.  Some of these interactions may be 
caught by reanalyzing the design without users, using 
techniques like the cognitive walkthrough.  Others may not 
show up without user testing.

When should the iterations stop?  If you've defined specific 
usability objectives (see hypertopic on Managing the Design 
Process), then iteration should be stopped when they are met.  
Otherwise, this will often be a management decision that 
balances the costs and benefits of further improvement 
against the need to get the product to market or, in in-house 
projects, into use.    
  
--------------------
1.9 Build the Design
--------------------

The key guideline in building the interface is to build it 
for change.  If you've been using a UIMS for prototyping, 
then you're already close to a finished product.  If you've 
been using some other prototyping system, now is the time to 
switch to a UIMS or, perhaps, to an object-oriented 
programming environment.  Try to anticipate minor changes 
with easily changed variables.  For example, if you have to 
write your own display routine for a specialized menu, don't 
hardcode parameters such as size, color, or number of items.  
And try to anticipate major changes with code that is cleanly 
modular.  If a later revision of the design requires that 
your specialized menu be replaced by some more generic 
function, the code changes should be trivial.  These sound 
like ordinary guidelines for good programming, and indeed 
they are.  But they are especially important for the user 
interface, which often represents more than half the code of 
a commercial product.

---------------------
1.10 Track the Design
---------------------

A fundamental principle of this book is that interface 
designers should not be a special group isolated from the 
rest of the system development effort.  If this principle is 
to hold, then the designer must have contact with users after 
the design hits the street.  In fact, it's easy to argue that 
this should be the case in any organization, because 
continued awareness of users and their real needs is a key 
requirement for a good designer.

One way to put designers in contact with users is to rotate 
them into temporary duty on the customer hotline.  Another 
important point of contact for large systems is user group 
meetings.  Managers also take advantage of these 
opportunities to see how real users react to the products 
they are selling.

Besides helping to answer the obvious question of whether the 
system is doing what it's designed to do, interactions with 
users can also yield surprises about other applications that 
have been found for the product, possibly opening up new 
market opportunities.  This information can feed back into 
the design process as improved task descriptions for the next 
revision and better understanding on the part of the 
designer.

----------------------
1.11 Change the Design
----------------------

In today's computer market there are few if any software 
products that can maintain their sales without regular 
upgrades.  No matter how well the product is initially 
designed to fit its task and users, it will probably be 
inadequate in a few years.  Tasks and users both change.  
Work patterns change because of the product itself, as well 
as because of other new hardware and software products.  
Users gain new skills and new expectations.  Designers need 
to stay abreast of these changes, not only by watching the 
workplace in which their products are installed, but also by 
watching for developments in other parts of society, such as 
other work situations, homes, and the entertainment industry.  
The next revision of the design should be a response not only 
to problems but also to opportunities. 



============================================================
HyperTopic:  Managing the Design Process
------------------------------------------------------------

* Task-Oriented vs. Waterfall Design *

The traditional "waterfall" model of software design starts 
with a requirements analysis step that is performed by 
systems analysts who are usually not the interface designers.  
These requirements are transformed into system 
specifications, and eventually the hardware, underlying 
software, and user interface are designed to meet those 
specifications.

The waterfall model has proven to be a poor approach to 
software that has an important user interface component.  As 
this chapter describes, the successful interface designer 
needs a deep understanding of the user's task and how the 
task fits into the rest of the user's work.  That 
understanding can't be derived from a set of abstract 
specifications.  Further, our experience has shown that 
several design iterations are essential in producing an 
effective interface.  The traditional waterfall model simply 
doesn't allow those iterations.

* The Design Team *

Because the task-centered design methodology spreads the 
activities of interface design throughout the software design 
and life cycle, the interface can't be produced or analyzed 
at one point by a group of interface specialists.  The job of 
building a good interface has to be taken on by the team that 
designs the product as a whole.

The design team needs to be composed of persons with a 
variety of skills who share several common characteristics.  
They need to care about users, they need to have experience 
with both bad and good interfaces, and they need to be 
committed to and optimistic about creating an effective 
system.  The team should include representatives from the 
entire range of interface-related areas: programmers, 
technical writers, training package developers, and marketing 
specialists.  The team might include a user-interface 
analyst, but that's not essential.  A shared commitment to 
interface quality, along with appropriate opportunities to 
interact with real users, will produce high quality 
interfaces for all but the most complex or critical 
interfaces.     

* Responsibility *

Responsibility for the entire interface effort should be 
centralized.  In particular, the designers who create the 
software shouldn't sign off on their product and hand it off 
to an entirely separate group that creates the manuals, who 
then hand off to another group that handles training.  All of 
these activities need to be coordinated, and the only way to 
achieve that is through central management.

* Usability Objectives * 

Serious corporate management efforts may require you to 
produce specific numbers that quantify usability.  Usability 
objectives are target values for things such as speed to 
perform representative tasks and number of errors allowable.  
These can be used to motivate designers and support resource 
allocation decisions.  The target values can be selected to 
beat the competition or to meet the functional needs of well-
defined tasks.

(For more information on management, see Appendix M.)

[end hypertopic]--------------------------------------------

----------
* Chapter 2
*
* Getting to Know Users and Their Tasks
*
*


To get a good interface you have to figure out who is going 
to use it to do what. You may think your idea for a new 
system is so wonderful that everyone will want it, though you 
can't think of a really specific example, and that it will be 
useful in some way to people, even though you can't say just 
how. But history suggests you will be wrong. Even systems 
that turned out to be useful in unexpected ways, like the 
spreadsheet, started out by being useful in some expected 
ways.


============================================================
Example:  The Illusory Customers
------------------------------------------------------------

There was a startup here in Boulder a few years back that 
wanted to build a system to help people build intelligent 
tutoring systems. They raised a bundle of money, brought a 
lot of smart people in, and went to work. But they didn't 
stop to figure out EXACTLY WHO would use the system to do 
EXACTLY WHAT.  The concept seemed too good, in those palmy 
days of AI madness, to require that kind of pedestrianism. 
The lack of specificity created some problems internally, 
since it was hard to make good decisions about what aspects 
of the new system were important. But the trouble became 
critical when the time came to line up test users, people who 
would try out the software and provide feedback to the 
developers. There were no takers! Not only were there no 
people waiting to fork out cash for the tool, there weren't 
even people who would take it for nothing. And this wasn't 
because the work wasn't quality. People just didn't want to 
do what the tool was supposed to help them do.

The company didn't just roll over; they searched around for 
something that people did want to do that they could do with 
something like the tool that had been built. Not surprisingly 
this didn't work out and the company folded its tents when 
the money ran out.

[end example]-----------------------------------------------


You may not have needed selling on this point. "Everybody" 
knows you have to do some kind of requirements analysis. Yes, 
but based on what, and in what form? Our advice is to insist 
that your requirements be grounded in information about real, 
individual people and real tasks that they really want to 
perform. Get soft about this and the illusions start to creep 
in and before you know it you've got another system that 
everybody wants except people you can actually find.


============================================================
HyperTopic:  Contracts and Requirements
------------------------------------------------------------

"Fortunately I don't have to worry about this. I work on 
contract stuff and all the requirements have been spelled out 
for me before I start."

Not so fast! It's one thing to meet the requirements of a 
contract and another thing to build a good system. Are 
anybody's interests really served if you build a system that 
meets spec but is a failure? That's what is likely to happen 
if you work to requirements that have not been grounded in 
reality, even if it's not your fault. Being selfish, will you 
get repeat business, or will you get a good reputation from 
work like this?

Clayton did once talk with a contract developer who assured 
him that on his current job the success of the system was 
really not an issue under any conceivable future (no 
possibility of repeat business, etc.) He has also heard of 
third-world "development" projects in which the real game is 
to please the bureaucrat who turns the tap on the (U.S.-
supplied) "development" money, rather than to make something 
work. But life is too valuable to spend on activities like 
these. Find something to do that matters.

[end hypertopic]--------------------------------------------



--------------------------------
2.1  Getting in Touch With Users
--------------------------------

So here's what to do. The first step is to find some real 
people who would be potential users of what you are going to 
build. If you can't find any you need to worry a lot. If you 
can't find them now, where will they come from when it's time 
to buy? When you have found some, get them to spend some time 
with you discussing what they do and how your system might 
fit in. Are they too busy to do this? Then they'll probably 
be too busy to care about your system after it exists. Do you 
think the idea is a real winner, and they will care if you 
explain it to them? Then buy their time in some way. Find 
people in your target group who are technology nuts and 
who'll talk with you because you can show them technology. Or 
go to a professional meeting and offer a unique T-shirt to 
people who'll talk with you (yes, there are people whose time 
is too expensive for you to buy for money who will work with 
you for a shirt or a coffee mug).


============================================================
HyperTopic:  Generic and Designer Users
------------------------------------------------------------

"I don't have to bother about this stuff. My system will be a 
tool for any UNIX user, no matter what they are working on. 
There's no special user population I'm trying to support."

Unfortunately experience shows that many ideas that are 
supposed to be good for everybody aren't good for anybody. 
Why not check by finding somebody and making sure it's good 
at least for them?

"Well, I'm somebody and my tool is good for me."

Two points here. First, is it REALLY  good for you? Do you 
actually USE it? Never work on something if you ought to be a 
user for it but you aren't. It's amazing how often this 
principle is violated. Second, there are lots of reasons why 
things often seem more useful to their designers than they do 
to other people. A big one is that the designer builds up his 
or her understanding of the thing over a long time and with a 
lot of thought. Usually the user wants to understand it right 
away, and often can't (Bruce Tognazzini makes this point very 
well in "Tog on Interface" Reading, MA: Addison Wesley, 1992, 
p. 8).

[end hypertopic]--------------------------------------------



------------------------------------
2.2  Learning About the Users' Tasks
------------------------------------

Once you have some people to talk with, develop CONCRETE, 
DETAILED EXAMPLES of tasks they perform or want to perform 
that your system should support. Here's how this went for 
Clayton and colleagues in a recent project, disguised to 
avoid embarrassing anybody.

The aim was to develop a system for modelling traffic: street 
layout, traffic volumes, accidents and the like. The system 
was to provide a flexible, graphical interface that would 
make it easy to tweak the model and examine the results. We 
had good access to potential users, because the project was 
sponsored by an organization that included people who 
currently use an existing model that the new one was to 
replace. 

But there was a delicate issue here, that you will often 
face. The particular people providing money for the project 
were not the users themselves, but a staff organization whose 
mission was to look after the needs of the users. Sounds OK? 
It's not: it meant that our direct contact was not with the 
people who really know firsthand what the problems are but 
people who are supposed to know the problems secondhand, a 
very different thing. Fortunately we knew what we wanted and 
were able to arrange a series of meetings with real users.

In these meetings we developed a list of twelve things the 
users would actually want to do with the system. They were 
specific, as for example:


     Change the speed limit on Canyon Boulevard eastbound
     between Arapahoe and 9th. Calculate projected traffic 
     flows on Arapahoe west of 6th assuming Canyon speeds 
     between 25 and 55 in increments of 5 mph.


Notice a few things about this example.

* It says what the user wants to do but does not say how the 
user would do it. *

As stated, this task does not make any assumptions about the 
nature of the modelling tool or its interface. Therefore it 
can be used to compare different design alternatives for the 
system and interface in a fair way. If we said "change the 
speed limit by selecting a new value from a menu" we would 
have prejudged the right way for the user to perform this 
part of the task.

* It is very specific. *

Not only does it say exactly what the user wants to do, it 
actually specifies particular streets. What's the point of 
this? It means that we can fill out this description of the 
task with any other details that may become relevant in 
evaluating designs. In fact, it forces us to do this. For 
example, if the model needs to divide streets into separate 
pieces for purposes of analysis, and the user then needs to 
select a number of pieces to do an analysis for a stretch of 
street, we can see in detail how this would work out for the 
real Canyon Boulevard. We can't avoid the problem as we could 
if we were thinking of any old generic street.

Dennis Wixon has an example that makes this point (In M. 
Rudissill, T. McKay, C. Lewis, and P.G. Polson (Eds.), 
"Human-Computer Interaction Design: Success Cases, Emerging 
Methods, and Real-World Context." Morgan Kaufman. In press.).  
Wixon and colleagues were developing an interface for a file 
management system. It passed lab tests with flying colors, 
but bombed as soon as customers got it. The problem was that 
it had a scrolling file list that was (say) twenty characters 
wide, but the file names customers used were very long, and 
in fact often identical for more than twenty characters (the 
names were made up by concatenating various qualifiers, and 
for many names the first several qualifiers would be the 
same.) Customers were not amused by needing to select from a 
scrolling list of umpty-ump identical entries that stood for 
different files. And this wasn't an oddball case, it was in 
fact typical. How had it been missed in the lab tests? Nobody 
thought it would matter what specific file names you used for 
the test, so of course they were all short.

* It describes a complete job. *

Note that the task doesn't just say to fiddle the speed limit 
on Canyon, or just to calculate projections for Arapahoe. It 
says the user wants to do both. This means that in seeing how 
this task plays out for a particular design of the interface 
we are forced to consider how features of the interface work 
together, not just how reasonable they may look separately.

We once evaluated a phone-in bank service that had done well 
in lab tests. People had no trouble checking their balances, 
finding out if checks had cleared, and the like. But when we 
looked at what was involved in finding if a check had cleared 
AND THEN looking at a balance, we found big problems. The 
interface was supposed to support this kind of transition 
between functions, but the test tasks used in the lab had not 
required them.

Describing complete jobs is a key feature of our approach, 
and it's different from the usual way of doing things. 
Usually requirements lists are just that: lists of little 
things the system has to do. Meeting this kind of requirement 
does little to ensure that users can do a real job without 
going crazy: it just ensures that they can do all the PARTS 
of a real job.

An important angle on the complete job issue is seeing where 
inputs come from and where outputs go. In the example 
problem, where does the model the user is going to tweak come 
from? How does he or she obtain it? If there aren't good 
answers to these questions the system will be no good in 
practice, even if it does the tweaking and calculating parts 
very well. 

Clayton worked on an early business graphics package whose 
sales were disappointing. Customer visits (done after ship, 
not before development when they should have been done) 
showed that the problem was that the package worked well when 
users had numbers to type in to make a graph, but badly when 
numbers were already in the system and needed to be extracted 
from a file. One user had temporarily hired typists to 
transcribe numbers from one screen, where a data file was 
displayed, onto another screen where the graph package was 
running. He was not eager to continue this arrangement. The 
majority of uses we saw were of this get-data-from-a-file 
kind, so the system was unsuited to requirements even though 
it did a good job on making the graph itself, the part of the 
whole job on which the designers concentrated.

So you want to choose tasks that represent complete jobs, and 
you want to be sure to scrutinize the edges of the tasks. 
Where does stuff come in from? Where does it go? What has to 
happen next?

* The tasks should say who the users are. *

In the highway example we were dealing with a small, close-
knit group of users, so we didn't specify in our example 
tasks WHO would be doing what: we took it as given. Probably 
we should have worried about this more, and probably you 
should. The success of a design can be influenced strongly by 
what users know, how the tasks supported by the system fit 
into other work they have to do, and the like. So you need to 
get a fix on these things early in design.

The design of Oncocin, a sophisticated cancer therapy 
advisor, illustrates what's at stake (Musen, M.A., Fagan, 
L.M., and Shortliffe, E.H. "Graphical specification  of 
procedural knowledge for an expert system. In J.A. Hendler 
[Ed.], "Expert Systems: The User Interface." Norwood, NJ: 
Ablex, 1988, p. 15). Earlier experience with doctor users had 
shown that they are willing to invest very little time in 
becoming familiar with a new system. A system to be used 
directly by doctors therefore has to be different from one to 
be used by medical technicians, who can be told they HAVE to 
learn a new tool. The Oncocin designers needed to decide up 
front whether their users would be doctors or would be 
technicians working in support of doctors. They went for 
direct use by doctors. The interface they came up with is as 
much as possible a faithful copy of the paper forms for 
specifying therapy that doctors were already using. 

So what should you say about users in specifying your tasks? 
If possible, name names. This allows you to get more 
information if it becomes relevant, just as saying it's 
Arapahoe Avenue allows you to bring in more detail about the 
task if you need to. Beyond that you should note 
characteristics of the users that you already know will be 
important, such as what their job is and what expertise they 
have.

In choosing the sample tasks for the traffic modelling system 
we were guided by two objectives. First, we wanted to be sure 
that we had examples that illustrated the kinds of support 
that we as designers thought the system should provide. That 
is, we had some general ideas about what the system was 
supposed to be good for, and we tried to find tasks that were 
examples of these. But second, we needed to reflect the 
interests of potential users in the examples. So we tried to 
find tasks that illustrated proposed functionality in the 
context of work users really wanted to do.

In the process some possible functions for the system dropped 
out. We had envisioned that the system might include some 
optimization functions that would manipulate the model to 
find the best of some range of alternatives with respect to 
some measure of quality. Users had no interest in this. They 
preferred to solve such problems by framing and evaluating 
alternatives themselves rather than having the system do 
this.

This is not an uncommon conflict, and one without a simple 
resolution. We thought, and still think, that users would 
eventually come to want optimization functions once more 
pressing modelling needs were met, so we didn't want to just 
take the users' word on this. But we put optimization on the 
back burner to be pushed again in the future.

This illustrates a key point about input from users: users 
are NOT always right. They cannot anticipate with complete 
accuracy how they will use new technology. As a designer your 
job is to build a system that users will want when it gets 
here, not to build the system users say they want as they see 
things today. You may well have insight into the future that 
users lack. But you need to be very careful about this. If 
you are like most designers, an outsider in the domain of 
work you are trying to support, you have to recognize that 
users know a whole lot more about what they are doing than 
you do. If you can't get users interested in your hot new 
idea, however hard you try to draw them into it, you're 
probably missing something. 


============================================================
HyperTopic:  Participatory Design
------------------------------------------------------------

In our discussion we have been assuming a split between the 
roles of designers and users that has been traditional in 
U.S. system design. Designers are not users; they gather 
information from users and reflect it in systems they build; 
they give these systems to users who use them or not. There 
is an alternative approach, pioneered by workers in 
Scandinavia, that rejects this structure. In participatory 
design, systems are designed by designers and users working 
together: a slogan is DESIGNING WITH rather than DESIGNING 
FOR. The power to make the system be one way rather than 
another is not reserved for the designers, as it is in most 
U.S. design practice, but rather is shared by designers and 
users working in collaboration.

The contrast between participatory design and standard U.S. 
practice reflects deep differences in political and 
philosophical outlook between Europe and the U.S.. Most 
European countries give workers very broad influence on 
working conditions, which are much more strictly regulated 
than in the U.S.. In many countries workers must have seats 
on the boards of directors of companies, and workers must be 
consulted on the introduction of new technology in the 
workplace. With this view of workers it is natural to think 
that workers should have a direct hand in shaping the systems 
they have to use. By contrast the prevailing view in the U.S. 
is that management should just decide what systems are good 
for productivity and then impose them on workers, whose views 
basically don't matter.

Many people in the U.S., if they think about these matters at 
all, assume that the U.S. way of doing things must be right. 
What is your reaction when you hear that in some European 
countries it is illegal to make someone work in a room 
without a window? Does that seem silly, or maybe wrongheaded, 
because of the restriction in places on freedom of 
enterprise? What do you think about it when you also learn 
that a number of countries in Europe have higher per capita 
productivity than the U.S., and that the U.S. is steadily 
losing export position, especially in advanced industries, 
and holding its own primarily in commodity exports like farm 
produce?  For a fascinating, disturbing, and constructive 
look at these and related issues, read the book "The 
Competitive Advantage of Nations," by Michael Porter (New 
York: Free Press, 1990). 

You can find a lengthy discussion of participatory design in 
the journal  Human-Computer Interaction,  (Floyd, C., Mehl, 
W.-M., Reisin, F.-M., Schmidt, G., and Wolf, G. "Out of 
Scandinavia: Alternative approaches to software design and 
system development." Human-Computer Interaction, 4 (1989), 
pp. 252-350), and a short and sweet discussion in an article 
by Jeanette Blomberg and Austin Henderson of Xerox in the 
CHI'90 proceedings (Blomberg, A.L. and Henderson, A. 
"Reflections on participatory design." In Proc. CHI'90 
Conference on Human Factors in Computer Systems. New York: 
ACM, 1990, pp. 353-359).  Blomberg and Henderson stress three 
defining attributes of participatory design: the goal of the 
activity is to improve the worklife of users (not, for 
example, to demonstrate how neat object-oriented technology 
is); the activity is collaborative, with all goals and 
decisions actively negotiated and not imposed; the activity 
is iterative, in that ideas are tested and adjusted by seeing 
how they play out in practice.

It's pretty easy to see how one could approach participatory 
design in in-house projects, though it would not be easy to 
get your organization actually to do it. For in-house 
projects it will be true at some level that designers and 
users share the same goals, though in the U.S. context these 
goals may not have much to do with the quality of worklife. 
But U.S. organizations usually have job demarcations which 
make it hard to get participatory design going. Usually, if 
my job is to be a user it is not to be a designer or to work 
on designs. That's the province of "experts" employed for the 
purpose, even though they have no idea what the real problems 
are that need to be solved.

For commercial projects there are further challenges. At 
bottom, your objective as a commercial developer may really 
not be to improve the quality of somebody else's work life, 
but rather to make money for yourself. So you don't have the 
right goal to begin with. 

There are two ways to go from here. One is to forget about 
the defining goals of participatory design and go through the 
motions of it in service of your selfish goals. The idea is 
that you hope to produce a better design, and hence make more 
money, by engaging users in collaboration focussed on the 
user's goals. To draw users in to making the considerable 
investment of time they would have to make to work with you, 
you would offer them a piece of the action. 

Developing new technology in close partnership with potential 
users like this is a good idea in many industries for lots of 
reasons not restricted to the peculiarities of user 
interfaces. As Michael Porter recounts, the modern printing 
press was developed by a new technology company that was 
supported by some of its potential users, big English 
newspapers. Such a relationship gets you the information you 
need to make your system really useful, and hence successful, 
as well as developing an early market.

Another response to the mismatch of your goal of making money 
and the participatory design goal of improving the quality of 
work life is to change your goal. Will money actually make 
you happy? Of course not. Will improving somebody's work life 
make you happy? Maybe so, if the work involved is itself 
something worthwhile, or if you just take satisfaction in 
doing something well. Even if you can't get this unselfish 
the logic of the situation is that you may do better all 
around, including monetarily, if you really care about the 
people who will use your system and what they do than if you 
only care about the money.

[end hypertopic]--------------------------------------------


------------------------------
2.3  Using the Tasks in Design
------------------------------

Back to the traffic modelling system and our sample tasks. 
What did we do with them after we got them? Taking a look at 
their fate may clarify what the tasks should be like, as well 
as helping to persuade you that it's worth defining them.

Our first step was to write up descriptions of all the tasks 
and circulate them to the users (remember, we're back in us-
versus-them mode, with designers and users clearly different 
teams.) We included queries for more information where we 
felt the original discussion had left some details out. And 
we got corrections, clarifications, and suggestions back 
which were incorporated into the written descriptions.

We then roughed out an interface design and produced a 
SCENARIO for each of the sample tasks. A scenario spells out 
what a user would have to do and what he or she would see 
step-by-step in performing a task using a given system. The 
key distinction between a scenario and a task is that a 
scenario is design-specific, in that it shows how a task 
would be performed if you adopt a particular design, while 
the task itself is design-independent: it's something the 
user wants to do regardless of what design is chosen. 
Developing the scenarios forced us to get specific about our 
design, and it forced us to consider how the various features 
of the system would work together to accomplish real work. We 
could settle arguments about different ways of doing things 
in the interface by seeing how they played out for our 
example tasks.

Handling design arguments is a key issue, and having specific 
tasks to work with really helps. Interface design is full of 
issues that look as if they could be settled in the abstract 
but really can't. Unfortunately, designers, who often prefer 
to look at questions in the abstract, waste huge amounts of 
time on pointless arguments as a result. 

For example, in our interface users select graphical objects 
from a palette and place them on the screen. They do this by 
clicking on an object in the palette and then clicking where 
they want to put it. Now, if they want to place another 
object of the same kind should they be made to click again on 
the palette or can they just click on a new location? You 
can't settle the matter by arguing about it on general 
grounds. 

You can settle it by looking at the CONTEXT in which this 
operation actually occurs. If the user wants to adjust the 
position of an object after placing it, and you decide that 
clicking again somewhere places a new object, and if it's 
legal to pile objects up in the same place, then you have 
trouble. How will you select an object for purposes of 
adjustment if a click means "put another object down"? On the 
other hand, if your tasks don't require much adjustment, but 
do require repeated placement of the same kind of object, 
you're pushed the other way. Our tasks seemed to us to 
require adjustment more than repeated placement, so we went 
the first way.

This example brings up an important point about using the 
example tasks. It's important to remember that they are ONLY 
EXAMPLES. Often, as in this case, a decision requires you to 
look beyond the specific examples you have and make a 
judgement about what will be common and what will be 
uncommon. You can't do this just by taking an inventory of 
the specific examples you chose. You can't defend a crummy 
design by saying that it handles all the examples, any more 
than you can defend a crummy design by saying it meets any 
other kind of spec.

We represented our scenarios with STORYBOARDS, which are 
sequences of sketches showing what the screen would show, and 
what actions the user would take, at key points in each task. 
We then showed these to the users, stepping them through the 
tasks. Here we saw a big gain from the use of the sample 
tasks. They allowed us to tell the users what they really 
wanted to know about our proposed design, which was what it 
would be like to use it to do real work. A traditional design 
description, showing all the screens, menus, and so forth, 
out of the context of a real task, is pretty meaningless to 
users, and so they can't provide any useful reaction to it. 
Our scenarios let users see what the design would really give 
them.

"This sample task idea seems crazy. What if you leave 
something out? And won't your design be distorted by the 
examples you happen to choose? And how do you know the design 
will work for anything OTHER than your examples?" There is a 
risk with any spec technique that you will leave something 
out. In choosing your sample tasks you do whatever you would 
do in any other method to be sure the important requirements 
are reflected. As noted above, you treat the sample tasks as 
examples. Using them does not relieve you of the 
responsibility of thinking about how other tasks would be 
handled. But it's better to be sure that your design can do a 
good job on at least some real tasks, and that it has a good 
chance of working on other tasks, because you've tried to 
design for generality, than to trust exclusively in your 
ability to design for generality. It's the same as that point 
about users: if a system is supposed to be good for EVERYBODY  
you'd better be sure it's good for SOMEBODY.


============================================================
HyperTopic: Integrating Task-Centered Design and Traditional 
Requirements Analysis
------------------------------------------------------------

If you're working for a small company or developing small 
projects for a few internal users at a large firm, the task-
centered design approach may be all you need.  But for larger 
projects, you'll probably have to work within the structure 
of an established software engineering procedure.  How to 
apply task-centered principles within that procedure will 
vary depending on the software engineering approach used at 
your company.  But we can give some general guidelines that 
are especially useful in the early stages of development.

Most large software projects are developed using some version 
of the "waterfall method."  The basic waterfall method 
assumes that a piece of software is produced through a 
clearly defined series of steps, or "phases":

	- Requirements analysis
	- Specification
	- Planning
	- Design
	- Implementation
	- Integration
	- Maintenance.

In its strictest version, this method states that each phase 
must be completed before the next phase can begin, and that 
there's no chance (and no reason) to return to an earlier 
phase to redefine a system as its being developed.  

Most software engineering specialists today realize that this 
approach is unrealistic.  It was developed in the era of 
punch cards and mainframes, so it doesn't have a real place 
for considerations of interactive systems.  Even in the 
mainframe era it was less than successful, because the 
definition of what's required inevitably changes as the 
system is developed.

Various modifications to the phases of the waterfall method 
and their interaction have been proposed.  However, it's not 
unusual to find productive software development environments 
that still incorporate many steps of the method, partly for 
historical reasons and partly because the approach helps to 
define responsibilities and costs for various activities 
within a large software project.  With some effort, the task-
centered design approach can supplement the early stages of a 
waterfall environment.

* Requirements Analysis *

The waterfall method's initial "Requirements Analysis" phase 
describes the activity of defining the precise needs that the 
software must meet.  These needs are defined in terms of the 
users and the their environment, with intentionally no 
reference to how the needs will actually be met by the 
proposed system.

This is exactly the same approach as we suggest for 
describing representative tasks:  define what the user needs 
to do, not how it will be done.  The difference is that the 
representative tasks in task-centered design are complete, 
real, detailed examples of things users actually need to do.  
The requirements produced by traditional software 
engineering, on the other hand, are abstract descriptions of 
parts of those representative tasks.

This is an important distinction, and we want to emphasize it 
most strongly:

      Task-centered design focuses on REAL, COMPLETE,
      REPRESENTATIVE tasks.  Traditional requirements
      analysis looks at ABSTRACT, PARTIAL task elements.

Here's an example.  For a document processing system, a 
representative task might be to produce this book.  Not to 
produce "a book," but to produce "version 1 of Task-Centered 
Design, by Lewis and Rieman."  That representative task 
supplements the detailed partial tasks collected in 
traditional requirements analysis, which might include things 
such as "key in text" and "check spelling" and "print the 
document." 

So if you're doing a traditional requirements analysis, you 
need to supplement it by collecting some representative 
tasks.  The two approaches complement each other nicely.  The 
traditional approach helps to ensure that all important 
functions of the system are recognized, while the 
representative tasks in the task-centered approach provide an 
integrated picture of those functions working together.

* Specification *

In the traditional "Specifications" phase of software 
engineering, the requirements are used to produce a 
description of the system that includes the details needed by 
the software designers and implementers.  The customers -- 
the end users -- can then sign off on this document, and the 
software team can begin to plan and design the actual system.  
This sounds like great stuff from a management point of view, 
but it practice it often falls apart.  Users aren't experts 
at reading specifications documents, and they have trouble 
imagining how the system will actually perform.  Various 
alternatives to written specifications have been proposed, 
including prototypes and a more iterative approach to design, 
both of which fit nicely into the task-centered design 
approach.

However, even if you're still doing written specifications, 
the representative tasks can be of value.  Include those 
tasks, with some details about how they will be performed, in 
the specification document.  The big win here is that the 
customers will be able to understand this part of the 
specifications.  It will also force the specifications writer 
to consider a complete task, which may catch problems that 
could be missed when single functions are considered 
individually.

Notice that the description of the proposed software hasn't 
quite reached the stage where you could do a complete 
"scenario," as we have defined it.  Many of the details, such 
as the names of menu items, the distribution of functionality 
among dialog boxes, etc., remain to be defined.  But a high-
level overview of the interactions can be described, and 
doing this well is a test of your understanding of the users' 
needs.  

* Planning, Design, and Beyond *

From this point on, the strict waterfall method and the task-
centered design approach take very different paths.  Many of 
the principles we describe can be used in doing the first 
pass at system and interface design, but inherent in the 
task-centered approach is the need for iteration: it's very 
rare that the first design of an interface is a complete 
success.  Several iterations of testing and redesign are 
required, and that may well involve jumping backward through 
the phases of the waterfall method, something that's 
traditionally not allowed.  Fortunately, the strict forward-
moving method is seldom adhered to today.  Most development 
environments recognize the need for some iteration, and that 
should make it possible to accommodate the general spirit of 
the task-centered approach. 

[end hypertopic]--------------------------------------------

----------
*   Chapter 3
*
*   Creating the Initial Design
*
*


The foundation of good interface design is INTELLIGENT 
BORROWING. That is, you should be building your design on 
other people's good work rather than coming up with your own 
design ideas. Borrowing is important for three distinct 
reasons. First, given the level of quality of the best user 
interfaces today, it's unlikely that ideas you come up with 
will be as good as the best ideas you could borrow. Second, 
there's a good chance, if you borrow from the right sources, 
that many of your users will already understand interface 
features that you borrow, whereas they'd have to invest in 
learning about features you invent. Finally, borrowing can 
save you tremendous effort in design and implementation and 
often in maintenance as well.


============================================================
HyperTopic:  "Won't I get sued if I follow your advice?"
------------------------------------------------------------

As you read through this chapter you'll realize that much of 
the borrowing we recommend is not only allowed, it's actually 
encouraged by the developers of the original system.  Apple 
Computer, for example, provides style guides, software 
toolkits, and other support for developers who want to 
produce Macintosh programs that look and act similar to all 
the other Macintosh programs.   

In addition, there are a lot of other things you can copy 
without infringing on the rights of other companies.  
Unfortunately, there's no clear and simple rule that defines 
those rights.  Appendix L gives an overview of the legal 
principles and provides a list of "boundary markers," 
examples of things that can and cannot be legally copied 
under the current laws.  The development process we recommend 
is to keep those boundary markers in mind, rough out your 
interface, and then talk over your decisions with your 
company's attorney.  If there's a central feature of the 
interface you're worried about, such as picking up an entire 
interface metaphor, you may want to get legal advice a little 
earlier.

Because the law is always changing (and this area of law is 
especially unsettled) there are some other things you need to 
do.  One is to read the trade journals and keep yourself 
abreast of the current state of the law.  Another is that 
your business plans should take into account the possibility 
that, no matter how careful you are, you may become involved 
in a lawsuit.       

[end hypertopic]--------------------------------------------


-------------------------------------------------
3.1  Working Within Existing Interface Frameworks
-------------------------------------------------

The first borrowing you should do is to work within one of 
the existing user interface frameworks, such as Macintosh, 
Motif or Windows. The choice may have already been made for 
you: in in-house development your users may have PCs and 
already be using Windows, or in commercial development it may 
be obvious that the market you are trying to reach (you've 
already found out a lot about who's in the market, if you're 
following our advice) is UNIX-based. If you want to address 
several platforms and environments you should adopt a 
framework like XVT that has multi-environment support.

The advantages of working in an existing framework are 
overwhelming, and you should think more than twice about 
participating in a project where you won't be using one. It's 
obvious that if users are already familiar with Windows there 
will be big gains for them if you go along. But there are 
also big advantages to you, as mentioned earlier. 

You'll get a STYLE GUIDE that describes the various interface 
features of the framework, such as menus, buttons, standard 
editable fields and the like. The style guide will also 
provide at least a little advice on how to map the interface 
requirements of your application onto these features, though 
the guides aren't an adequate source on this. This 
information saves you a tremendous amount of work: you can, 
and people in the old days often did, waste huge amounts of 
time designing scroll bars or ways to nest menus. Nowadays 
these things have been done for you, and better than you 
could do them yourself.

You also get SOFTWARE TOOLS for implementing your design. Not 
only does the framework have an agreed design for menus and 
buttons, but it also will have code that implements these 
things for you. We'll discuss these implementation aids in a 
later chapter.


============================================================
HyperTopic: One-of-a-Kind Hardware
------------------------------------------------------------

"We can't use any of the existing frameworks because of our 
special hardware, which we have to use because of military 
specs/the customer's hardware base/ the new psychotelekinetic 
interaction device we're supporting."

Make sure your schedule allows for the huge amount of extra 
work you are buying into, and make sure you are being paid 
enough. Also think about where your next job is coming from: 
the record of sustained success for onesy developments is not 
good, because of all the added costs. Try really hard to find 
a way to accommodate that psychotelekinetic device as an add-
on to one of the standard environments. 

[end hypertopic]--------------------------------------------


----------------------------------------
3.2  Making Use of Existing Applications
----------------------------------------

The next copying you ought to do is to find good existing 
applications that already provide some of the functionality 
you need and plan to incorporate those applications into your 
system. Do users need some database capabilities, and some 
ability to do calculations of the data they are dealing with 
in your application? They almost always do. You will not be 
able to develop your own Dbase, or your own Excel, that will 
be nearly as good, or as powerful, as existing products that 
have been shaped by intense and extended competition in the 
commercial market. Even if you could you and your users are 
still behind: many of them already know how to use Excel, and 
they gain nothing by having to learn about your version of a 
spreadsheet instead.


============================================================
Example: Monte Carlo Modelling Systems
------------------------------------------------------------

Suppose you want to do financial projections, such as you 
might do with a spreadsheet, but you need to represent 
uncertainty in the numbers you use: next year's sales should 
be somewhere around $1.5M, but they could be as low as about 
$1M or as high as $2M. Costs should be around $1.2M, but they 
could be as high as $1.4M or as low as $1M. So what's the 
gross profit picture for next year? You could use a regular 
spreadsheet by running various what-if's with different 
numbers, but if you have a few more parameters that gets 
tedious and error-prone. And suppose you think that sales and 
costs are probably correlated? Monte Carlo simulation is a 
modelling technique that lets you specify statistical 
distributions for parameters, and correlations between them, 
and estimates the distribution for resulting quantities by 
sampling from the distributions you provide.

Suppose you wanted to sell a Monte Carlo tool to the business 
world. You could try to build your own system from the ground 
up,  but you'd be wrong. The right thing to do, as Crystal 
Ball and @Risk have done, is to build and sell a spreadsheet 
add-on. Modern spreadsheets, and the systems in which they 
run, permit fairly easy communication between the spreadsheet 
and your code. This is a huge win, for the following reasons:

- The spreadsheet provides for you many functions which you 
would otherwise have to implement yourself, including data 
entry and specification of computations in the model.

- It provides these functions in a form many users already 
understand. In fact the same add-on can be made to work with 
more than one of the popular spreadsheets, so users can 
choose whichever spreadsheet they already know most about.

- The spreadsheet provides many functions that aren't part of 
what you HAVE TO do in your application but are significant 
enhancements that you get for nothing. For example, modern 
spreadsheets offer a wide range of graphical presentations of 
data.

- Chances are users will want to transfer data between your 
package and their spreadsheet anyway. That'll be much easier 
with the add-on than if you build a separate package.

- The spreadsheet can handle most if not all of the various 
environmental dependencies for you, such as drivers for 
various kinds of displays and printers. There is no way that 
you could afford to put as much coverage of environment 
options into your package as the spreadsheet developers, with 
their huge market, can afford to put in theirs.

[end example]-----------------------------------------------



------------------------------------------------------
3.3  Copying Interaction Techniques From Other Systems
------------------------------------------------------

Another kind of borrowing is copying specific interaction 
techniques from existing systems. If the style guides were 
good enough you might not have to do this, but the fact is 
the only way to get an adequate feel for how various 
interface features should be used, and how different kinds of 
information should be handled in an interface, is to look at 
what other applications are doing. The success of the 
Macintosh in developing a consistent interface style early in 
its life was based on the early release of a few programs 
whose interfaces served as models of good practice. An 
analogous consensus for the IBM PC doesn't really exist even 
today, but as it forms it is forming around prominent Windows 
applications like Excel or Word.

It follows from the need to borrow from other applications 
that you can't be a good designer without becoming familiar 
with leading applications. You have to seek them out, use 
them, and analyze them.

The key to "intelligent" borrowing, as contrasted with 
borrowing pure and simple, is knowing WHY things are done the 
way they are. If you know why an application used a tool 
palette rather than a menu of functions, then you have a 
chance of figuring out whether you want to have a palette or 
a menu. If you don't know why, you don't know whether the 
same or a different choice makes sense for you.

Bill Atkinson's MacPaint program was one of the standard-
setting early Macintosh programs, and it used a tool palette, 
a box on the side of the window containing icons. The icons 
on the palette stand for various functions like "enter text", 
"move view window", "draw a rectangle", and the like. Why was 
this a good design choice, rather than just listing these 
functions in a pull-down menu? In fact, some similar 
functions are listed in a pulldown menu called "goodies". So 
should you have a palette for what you are doing or not?

Here are some of the considerations:

* Operations on menus usually do not permit or require 
graphical specification of parameters, though they can 
require responding to queries presented in a dialog box. So 
an operation like "draw a rectangle", in which you would 
click on the corners of the intended rectangle, would be odd 
as a menu item.

* A palette selection actually enters a MODE, a special state 
in which things happen differently, and keeps you there. This 
doesn't happen when you make a menu selection. For example, 
if you select the tool for drawing rectangles from a palette, 
your mouse clicks get interpreted as corners of rectangle 
until you get out of rectangle drawing mode. If you selected 
"draw a rectangle" from a menu, assuming the designer hadn't 
been worried about the point above, you'd expect to be able 
to draw just one rectangle, and you'd have to go back to the 
menu to draw another one.

So a tool palette is appropriate when it's common to want to 
do a lot of one kind of thing rather than switching back and 
forth between different things.

* Modes are generally considered bad. An example which 
influenced a lot of thinking was the arrangement of input and 
command modes in early text editors, some of which are still 
around. In one of these editors what you typed would be 
interpreted either as text to be included in your document, 
if you were in input mode, or as a command, if you were in 
command mode. There were two big problems. First, if you 
forgot what mode you were in you were in trouble. Something 
you intended as text, if typed in command mode, could cause 
the system to do something dreadful like erase your file. 
Second, even if you remembered what mode you were in, you had 
the bother of changing modes when you needed to switch 
between entering text and entering commands.

* But modes controlled by a tool palette are considered OK 
because:
 - there is a change in the cursor to indicate what mode
   you are in, so it's harder to forget;
 - you only get into a mode by choosing a tool, so you 
   know you've done it;
 - it's easy to get out of a mode by choosing another tool.

* In a tool palette, tools are designated by icons, that is 
little pictures, whereas in menus the choices are indicated 
by text. There are two subissues here. First, for some 
operations, like drawing a rectangle, it's easy to come up 
with an easily interpretable and memorable icon, and for 
others it's not. So sometimes icons will be as good as or 
better than text, and sometimes not. Second, icons are 
squarish while text items are long and thin. This means icons 
PACK differently on the screen: you can have a bunch of icons 
close together for easy viewing and picking, while text items 
on a menu form a long column which can be hard to view and 
pick from.

So... this tells you that you should use a tool palette in 
your application if you have operations that are often 
repeated consecutively, and you can think of good icons for 
them, and they require mouse interaction after the selection 
of the operation to specify fully what the operation does.

Depending on the style guide you are using, you may or may 
not find a good, full discussion of matters like this. One of 
the places where experience will pay off the most for you, 
and where talking with more experienced designers will be 
most helpful, is working out this kind of rationale for the 
use of various interface features in different situations. 


============================================================
HyperTopic: Some Kinds of Why's
------------------------------------------------------------

Analyzing the why's of interface features is complicated and 
detailed, as the example showed. But it's possible to 
identify some broad kinds of arguments that crop up often.

* Geometrical and Movement Arguments *

Small targets are harder (and slower) to hit with a mouse 
than big targets; long mouse movements are slower than short 
ones; icons pack differently from text strings; more 
keystrokes take longer to type; switching between mouse and 
keyboard is slow.

* Memory Arguments *

It is easier to recognize something when you see it (for 
example on a menu) than it is to recall it from scratch (for 
example in typing in a command); it is hard to remember much 
information from one step in a process to another (so, for 
example, having help information available at the same time 
as the user carries out an operation is a good idea; more 
generally, information that is used together should be 
presented together); the interface should present key 
information, such as the current mode, rather than requiring 
the user to remember it.

* Problem-Solving Arguments *

Interface features should help the user to select operations 
that are relevant to their goals, by labelling the  
operations in ways that match the way the user thinks about 
his or her task; the user needs to know what an operation has 
actually done (the UNIX approach of saying nothing unless 
something goes wrong is useless if you are a learner and do 
not already know what the commands do); users will make 
mistakes, especially if they are exploring options, so give 
them a way to back out.

* Attention Arguments *

Information presented with a big change in the display is 
more likely to be read; information presented close to where 
the user is looking is more likely to be read; auditory 
signals cannot be ignored as easily as visual signals (this 
is a two-edged sword; sometimes you want to be able to ignore 
things).

* Convention arguments *

If you do things the way your users are familiar with, they 
will be happier; conventional ways of using features have 
stood the test of time, but any innovation you make has not 
and thus may suffer from hard-to-anticipate problems.

* Diversity Arguments *

Different users have different preferences for interaction 
styles, and some users have physical limitations that make it 
difficult or impossible to use certain features.  A blind 
user, for example, can work with textual menus using a device 
that translates on-screen text to audible speech, but 
graphical icons can't be translated by the device.  A person 
with impaired motor control may be able to type but may not 
have the fine hand control needed to use the mouse, while a 
person with the use of only one hand might have problems with 
two-key combinations and prefer the mouse and pulldown menus.  
For all of these users, providing more than one access to a 
function may be essential.


All of these statements are abstract. It can be hard to see 
how or whether they apply to a given design problem without 
some experience in applying them. Spend some time looking at 
a good interface and seeing if you can make sense of its 
features in terms of these ideas.

[end hypertopic]--------------------------------------------


============================================================
Example: Copying in the Traffic Modelling System.
------------------------------------------------------------

We did all of the above kinds of copying in the traffic 
modelling system. To begin with we incorporated a statistics 
package called S+ bodily: users needed to do statistical 
treatments and plots, and S+ already had implemented more 
than they would need. We were working in UNIX so it was 
fairly easy to run S+ as a separate process, send requests to 
it and bring back answers from it or have it present its 
output directly to users. We also adapted an existing package 
for diagram building called AgentSheets so that users could 
build their model in diagram form by pointing and clicking on 
graphical model elements. This was not a simple copy because 
AgentSheets needed to be extended slightly. 

AgentSheets is implemented in LISP, and we proposed to do 
other development in LISP, so we needed LISP-compatible 
software for other interface features that AgentSheets did 
not provide. We chose Garnet, a LISP-based user interface 
support package developed at Carnegie-Mellon University 
(CMU). Garnet is intended to provide very flexible support 
for people who want to create their own interface features, 
rather than adopting an existing framework like MOTIF. Since 
we didn't really need to create any new features it was not 
really a good choice for our purposes, but at the time we 
were doing the work we did not have LISP support for other 
options.

Our experience with Garnet is a good example of the costs of 
not copying enough. We had to implement interface features in 
Garnet that would be provided as standard parts of a system 
like MOTIF today. (Of course this is not a reflection on 
Garnet but on us: we were trying to use it for purposes for 
which it was not intended. Garnet was and is a very powerful 
tool for exploring new interface techniques such as 
demonstrational interfaces.)

Since Garnet was not intended to support any particular 
interface style it did not have a style guide. This was not a 
problem, because we simply copied stylistic features from 
other systems, especially the Macintosh. Our users (we knew 
exactly who they were) had no experience with ANY graphical 
user interface, so we considered ourselves free to use Mac-
style interaction even though we were implementing on a UNIX 
platform. But this was probably a bad copying decision, which 
we would not have made had it been clearer at the time how 
much acceptance MOTIF would get. One of the ways designers 
today are fortunate is that these choices have become 
clearer.

Against all of this background we could concentrate on a few 
areas of the design for which we did not find a clear 
precedent. One was allowing users to specify model inputs by 
typing in numbers or by designating a prepared file; another 
was how to control the execution of the model so as to 
explore various possible combinations of input values (recall 
the speed-limit study mentioned in the previous chapter); 
another was how to capture model results in a form that could 
be fed into further processing, so as to prepare a graph 
comparing results from different runs, for example. 

We didn't need to do anything very clever about these things. 
We represented data, whether model input or output, as 
graphical objects that could be connected to other model 
elements. These objects could be opened, exposing their 
contents for editing, and the opened object contained a file 
browser that could be used optionally to select a file from 
which values could be read or into which values could be 
placed for later use. Execution control was done by 
specifying input parameters and values to be used for them, 
along with other specifications of a run, in a dialog box.

[end example]-----------------------------------------------


----------------------------
3.4  When You Need to Invent
----------------------------

At some point in most projects you'll probably feel that 
you've done all the copying that you can, and that you've got 
design problems that really call for new solutions. Here are 
some things to do.

* Think again about copying. Have you really beaten the 
bushes enough for precedents? Make another try at locating a 
system that does the kind of thing you need. Ask more people 
for leads and ideas.

* Make sure the new feature is really important. Innovation 
is risky and expensive. It's just not worth it for a small 
refinement of your design. The new feature has to be central.

* Apply the whole process of this book to the design. This 
means you can't expect to come up with a good innovation just 
by thinking about it, any more than you can come up with a 
good interface just by thinking about it. Be careful and 
concrete in specifying the requirements for the innovation, 
that is, the context in which it must work. Rough out some 
alternatives. Analyze them, as discussed in the next chapter. 
Then try them out with users, as discussed in the chapter 
after that.

============================================================
Example: Tog's One-or-more Button.
------------------------------------------------------------

Bruce Tognazzini has a great example of process of innovation 
in "Tog on Interface" (Reading, MA: Addison Wesley, 1992), a 
book you should read, especially, but not only, if you are a 
Mac person. He recounts the design of a kind of button that 
requires the user to turn on at least one of them. Repeated 
try-outs with users were completely crucial to success.

[end example]-----------------------------------------------

============================================================
HyperTopic: The Good Old Days, When Designers Were Designers
------------------------------------------------------------

If you look at design case studies in the literature you are 
likely to be misled about what's involved in good design. 
Many of the most interesting case studies, such as those for 
the Xerox Star, come from a good while ago (Smith, D.C., 
Irby, C., Kimball, R., Verplank, W., and Harslem, E.  
"Designing the Star user Interface." Byte, 7:4 (April 1982), 
pp. 242-282). They tell you about designing something that 
was totally revolutionary in its day. Virtually every feature 
of the interface was an innovation, so virtually every 
feature was subjected individually to intensive design study 
including user testing. These studies tell you about the 
heroic age of design.

But you are probably not creating something totally 
revolutionary. In fact, as we've been advising, you should be 
trying hard not to, in most situations. 

Even contemporary case study reports can be misleading. These 
reports usually focus on the innovations, because that's 
where the news and interest are. This means you don't really 
learn how to get your job done from these studies.

[end hypertopic]--------------------------------------------


------------------------------------------------------
3.4  Graphic Design Principles
------------------------------------------------------

The graphic design of an interface involves decisions about 
issues such as where to put things on the screen, what size 
and font if type to use, and what colors will work best.  For 
these questions as for other, more substantive design issues, 
intelligent borrowing should be your first approach.  But 
that often leaves you with a lot of decisions still to be 
made.  Here are a few principles of graphic design that will 
not only make your interface more attractive, but will also 
make it more usable.  Each principle is accompanied by a 
description of WHY it's important, so you'll be able to 
consider the tradeoffs when there's a conflict between two 
principles or between a design principle and a borrowed 
technique.


* The Clustering Principle: Organize the screen into visually 
separate blocks of similar controls, preferably with a title 
for each block. *

"Controls," as we use the word here, include menus, dialog 
boxes, on-screen buttons, and any other graphic element that 
allows the user to interact with the computer.  Modern WIMP 
(Windows-Icons-Menus-Pointer) systems are a natural 
expression of the Clustering Principle.  Similar commands 
should be on the same menu, which places them in close 
proximity visually and gives them a single title.  Large 
numbers of commands related to a given area of functionality 
may also show up in a dialog box, again a visually defined 
block.

But the same principle should apply if you are designing a 
special control screen with many buttons or displays visible, 
perhaps a touch-screen interface.  The buttons for a given 
function should be grouped together, then visually delineated 
by color, or a bounding box, or surrounding space ("white 
space").  The principle should also be applied within WIMP 
systems when you design a dialog box: If there is a subgroup 
of related functions, put them together in the box.

There are two important reasons for the clustering principle.  
First, it helps users search for the command they need.  If 
you're looking for the "Print setup" menu, it's easier to 
find if it's in a box or menu with the label "Printer" then 
if it's one of hundreds of command buttons randomly 
distributed on the top of the screen.  Second, grouping 
commands together helps the user acquire a conceptual 
organization for facts about the program.  It's useful to 
know, for example, that Bold, Italic, and Outline are all one 
kind of font modification, while Times Roman, Palatino, and 
Courier are another kind.  (That distinction, common to most 
PC-based word processors, doesn't hold for many typesetting 
systems, where users have to acquire a different conceptual 
organization.)


* The Visibility Reflects Usefulness Principle:  Make 
frequently used controls obvious, visible, and easy to 
access; conversely, hide or shrink controls that are used 
less often. *

This is a principle that WIMP systems implement with dialog 
boxes and, in many recent systems, with "toolbars" of icons 
for frequently used functions.  The reasoning behind this 
principle is that users can quickly search a small set of 
controls, and if that set contains the most frequently used 
items, they'll be able to find and use those controls 
quickly.  A more extended search, through dialog boxes, for 
example, is justified for controls that are used 
infrequently.


* The Intelligent Consistency Principle:  Use similar screens 
for similar functions. *

This is similar to intelligent borrowing, but in this case 
you're borrowing from one part of your design and applying it 
to another part.  The reasoning should be obvious: Once users 
learn where the controls are on one screen (the "Help" 
button, for example), they should be able to apply that 
knowledge to other screens within the same system.

This approach lets you make a concentrated effort to design 
just a few attractive, workable screens, then modify those 
slightly for use in other parts of the application.

Be careful to use consistency in a meaningful way, however.  
Screens shouldn't look alike if they actually do 
significantly different things.  A critical error warning in 
a real-time system should produce a display that's very 
different from a help screen or an informational message.


* The Color As a Supplement Principle:  Don't rely on color 
to carry information; use it sparingly to emphasize 
information provided through other means. *

Color is much easier to misuse than to use well.  Different 
colors mean different things to different people, and that 
relationship varies greatly from culture to culture.  Red, 
for example, means danger in the U.S., death in Egypt, and 
life in India.  An additional problem is that some users 
can't distinguish colors: about 7 percent of all adults have 
some form of color vision deficiency.

A good principle for most interfaces is to design them in 
black and white, make sure they are workable, then add 
minimal color to the final design.  Color is certainly useful 
when a warning or informational message needs to stand out, 
but be sure to provide additional cues to users who can't 
perceive the color change.

Unless you're an experienced graphic designer, minimal color 
is also the best design principle for producing an attractive 
interface.  Try to stick with grays for most of the system, 
with a small amount of bright color in a logo or a label 
field to distinguish your product.  Remember that many users 
can -- and frequently do -- revise the color of their 
windows, highlighting, and other system parameters.  Build a 
product that will work with that user input, not one that 
fights it. 


* The Reduced Clutter Principle:  Don't put "too much" on the 
screen. *

This loosely defined principle is a good checkpoint to 
confirm that your design reflects the other principles listed 
above.  If only the most highly used controls are visible, 
and if controls are grouped into a small number of visual 
clusters, and if you've used minimal color, then the screen 
should be graphically attractive.

This is also a good principle to apply for issues that we 
haven't dealt with specifically.  Type size and font, for 
example:  the Reduced Clutter Principle would suggest that 
one or two type styles are sufficient.  Don't try to 
distinguish each menu by its own font, or work with a large 
range of sizes.  Users typically won't notice the 
distinction, but they will notice the clutter.

----------
*   Chapter 4
*
*   Evaluating the Design Without Users
*
*


Throughout this book we've emphasized the importance of 
bringing users into the interface design process.  However, 
as a designer you'll also need to evaluate the evolving 
design when no users are present.  Users' time  is almost 
never a free or unlimited resource.  Most users have their 
own work to do, and they're able to devote only limited time 
to your project.  When users do take time to look at your 
design, it should be as free as possible of problems.  This 
is a courtesy to the users, who shouldn't have to waste time 
on trivial bugs that you could have caught earlier.  It also 
helps build the users' respect for you as a professional, 
making it more likely that they will give the design effort 
serious attention.    

A second reason for evaluating a design without users is that a 
good evaluation can catch problems that an evaluation with only a 
few users may not reveal.  The numbers tell the story here:  An 
interface designed for a popular personal computer might be used 
by thousands of people, but it may be tested with only a few dozen 
users before beta release.  Every user will have a slightly 
different set of problems, and the testing won't uncover problems 
that the few users tested don't have.  It also won't uncover 
problems that users might have after they get more experience.  An 
evaluation without users won't uncover all the problems either.  
But doing both kinds of evaluation significantly improves the 
chances of success.

In this chapter we describe three approaches to evaluating an 
interface in the absence of users.  The first approach is the 
cognitive walkthrough, a task-oriented technique that fits 
especially well in the context of task-centered design.  The 
second approach is action analysis, which allows a designer to 
predict the time that an expert user would need to perform a task, 
and which forces the designer to take a detailed look at the 
interface.  The third approach is heuristic evaluation, a kind of 
check-list approach that catches a wide variety of problems but 
requires several evaluators who have some knowledge of usability 
problems.

We'll describe these techniques and show how each one applies to 
the analysis of a single interface.  The interface we'll look at 
is the "Chooser" in an early version of the Apple Macintosh 
operating system.  The Chooser lets the user select printers and 
printer options.  For our task-oriented evaluations, the task will 
be to turn on background printing.  

The Chooser is an interesting example because it's part of a 
system that was designed with usability and simplicity as 
paramount goals.  Nonetheless, we'll see that it has some 
potential problems.  Some of those problems have been corrected in 
later versions of the Mac operating system; others haven't, 
possibly because the structure of the interface is too deeply 
embedded in the functionality of the system, or possibly because 
the changes would be too disruptive to existing users.  (See the 
end of Appendix M for more thoughts on upgrading systems after 
they are in the field.)  

Take a few minutes before you read the rest of this chapter 
to look over the following description of the Chooser and 
write down any problems you find.


============================================================
Example: Selecting Background Printing with the Mac Chooser
------------------------------------------------------------

We've presented this example in the rough format that a 
system designer might use to describe a suggested system to 
his colleagues.  This is the point in an interface design 
when you should be using the techniques described in this 
chapter, either alone or as a group -- don't wait until after 
the system is implemented!

------------------------------------------------------------
START

User is working with word processor.  Task is to turn on 
background printing.  Screen shows the current application 
window and the following menubar of pulldown menus:

    ------------------------------------------
     @ File Edit Search Font Utilities
    ------------------------------------------

("@" stands for the apple icon.)

------------------------------------------------------------
ACTION 1:  Pull down the apple menu.

Apple pulldown menu looks like this:

      | @ |
       ------------------
      | About UltraWord  |
      | ---------------- |
      | Alarm Clock      |
      | Calculator       | 
      | Chooser          |
      | Control Panel    |
      | Find File        |
      | Keycaps          |
      | Scrapbook        |
       ------------------


------------------------------------------------------------
ACTION 2:  Select "Chooser" from the menu.

A dialog box appears:

      ---------------------------------------------------
     | [ ]                                               |
      ---------------------------------------------------
     |                                                   |
     |   --------------------    ----------------------  |
     |  | [laser printer   |^|  |                      | |
     |  | icon]            |-|  |                      | |
     |  |                  | |  |                      | |
     |  | [dot matrix      | |  |                      | |
     |  | printer icon]    |-|  |                      | |
     |  |                  |v|  |                      | |
     |   --------------------    ----------------------  |
     |                                                   |
     |                                                   |
     |                          User name:               |
     |                            --------------------   | 
     |                           | Sneezy             |  |
     |                            --------------------   |
     |                          Appletalk:               |
     |                            o active   * inactive  |
      ---------------------------------------------------


------------------------------------------------------------
ACTION 3:  Click on current printer type, which is Laser.

The laser printer icon highlights and new things appear
in the dialog box:

      ---------------------------------------------------
     | [ ]                                               |
      ---------------------------------------------------
     |                          Select a laser printer:  |
     |   --------------------    ----------------------  |
     |  | [LASER PRINTER   |^|  | Hotshot              | |
     |  | ICON (high-      |-|  | Mary's               | |
     |  | lighted)]        | |  | Last Chance          | |
     |  |                  | |  |                      | |
     |  | [dot matrix      |-|  |                      | |
     |  | printer icon]    |v|  |                      | |
     |   --------------------    ----------------------  |
     |                          Background printing      |
     |                             o On      * Off       |
     |                          User name:               |
     |                            --------------------   | 
     |                           | Sneezy             |  |
     |                            --------------------   |
     |                          Appletalk:               |
     |                            o active   * inactive  |
      ---------------------------------------------------



------------------------------------------------------------
ACTION 4:  Click the On button under background printing.

    The On button highlights and the Off button unhighlights.



------------------------------------------------------------
ACTION 5:  Click the Close Box in the upper left window.

    The screen appears as it did at startup.



[end example]-----------------------------------------------


---------------------------
4.1  Cognitive Walkthroughs
---------------------------

The cognitive walkthrough is a formalized way of imagining 
people's thoughts and actions when they use an interface for 
the first time.  Briefly, a walkthrough goes like this:  You 
have a prototype or a detailed design description of the 
interface, and you know who the users will be.  You select 
one of the tasks that the design is intended to support.  
Then you try to tell a believable story about each action a 
user has to take to do the task.  To make the story 
believable you have to motivate each of the user's actions, 
relying on the user's general knowledge and on the prompts 
and feedback provided by the interface.  If you can't tell a 
believable story about an action, then you've located a 
problem with the interface.


============================================================
Example:  A Quick Cognitive Walkthrough
------------------------------------------------------------

Here's a brief example of a cognitive walkthrough, just to 
get the feel of the process.  We're evaluating the interface 
to a personal desktop photocopier.  A design sketch of the 
machine shows a numeric keypad, a "Copy" button, and a push 
button on the back to turn on the power.  The machine 
automatically turns itself off after 5 minutes inactivity.  
The task is to copy a single page, and the user could be any 
office worker.  The actions the user needs to perform are to 
turn on the power, put the original on the machine, and press 
the "Copy" button.

In the walkthrough, we try to tell a believable story about 
the user's motivation and interaction with the machine at 
each action.  A first cut at the story for action number one 
goes something like this:  The user wants to make a copy and 
knows that the machine has to be turned on.  So she pushes 
the power button.  Then she goes on to the next action.

But this story isn't very believable.  We can agree that the 
user's general knowledge of office machines will make her 
think the machine needs to be turned on, just as she will 
know it should be plugged in.  But why shouldn't she assume 
that the machine is already on?  The interface description 
didn't specify a "power on" indicator.  And the user's 
background knowledge is likely to suggest that the machine is 
normally on, like it is in most offices.  Even if the user 
figures out that the machine is off, can she find the power 
switch?  It's on the back, and if the machine is on the 
user's desk, she can't see it without getting up.  The switch 
doesn't have any label, and it's not the kind of switch that 
usually turns on office equipment (a rocker switch is more 
common).  The conclusion of this single-action story leaves 
something to be desired as well.  Once the button is pushed, 
how does the user know the machine is on?  Does a fan start 
up that she can hear?  If nothing happens, she may decide 
this isn't the power switch and look for one somewhere else.

That's how the walkthrough goes.  When problems with the 
first action are identified, we pretend that everything has 
been fixed and we go on to evaluate the next action (putting 
the document on the machine).

[end example] ----------------------------------------------


You can see from the brief example that the walkthrough can 
uncover several kinds of problems.  It can question 
assumptions about what the users will be thinking ("why would 
a user think the machine needs to be switched on?").  It can 
identify controls that are obvious to the design engineer but 
may be hidden from the user's point of view ("the user wants 
to turn the machine on, but can she find the switch?").  It 
can suggest difficulties with labels and prompts ("the user 
wants to turn the machine on, but which is the power switch 
and which way is on?").  And it can note inadequate feedback, 
which may make the users balk and retrace their steps even 
after they've done the right thing ("how does the user know 
it's turned on?").
         
The walkthrough can also uncover shortcomings in the current 
specification, that is, not in the interface but in the way 
it is described.  Perhaps the copier design really was 
"intended" to have a power-on indicator, but it just didn't 
get written into the specs.  The walkthrough will ensure that 
the specs are more complete.  On occasion the walkthrough 
will also send the designer back to the users to discuss the 
task.  Is it reasonable to expect the users to turn on the 
copier before they make a copy?  Perhaps it should be on by 
default, or turn itself on when the "Copy" button is pressed.

Walkthroughs focus most clearly on problems that users will 
have when they first use an interface, without training.  For 
some systems, such as "walk-up-and-use" banking machines, 
this is obviously critical.  But the same considerations are 
also important for sophisticated computer programs that users 
might work with for several years.  Users often learn these 
complex programs incrementally, starting with little or no 
training, and learning new features as they need them.  If 
each task-oriented group of features can pass muster under 
the cognitive walkthrough, then the user will be able to 
progress smoothly from novice behavior to productive 
expertise.

One other point from the example:  Notice that we used some 
features of the task that were implicitly pulled from a 
detailed, situated understanding of the task: the user is 
sitting at a desk, so she can't see the power switch.  It 
would be impossible to include all relevant details like this 
in a written specification of the task.  The most successful 
walkthroughs will be done by designers who have been working 
closely with real users, so they can create a mental picture 
of those users in their actual environments.     

Now here's some details on performing walkthroughs and 
interpreting their results.

4.1.1  Who should do a walkthrough, and when?

If you're designing a small piece of the interface on your 
own, you can do your own, informal, "in your head" 
walkthroughs to monitor the design as you work.  
Periodically, as larger parts of the interface begin to 
coalesce, it's useful to get together with a group of people, 
including other designers and users, and do a walkthrough for 
a complete task.  One thing to keep in mind is that the 
walkthrough is really a tool for developing the interface, 
not for validating it.  You should go into a walkthrough 
expecting to find things that can be improved.  Because of 
this, we recommend that group walkthroughs be done by people 
who are roughly at the same level in the company hierarchy.  
The presence of high-level managers can turn the evaluation 
into a show, where the political questions associated with 
criticizing someone else's work overshadow the need to 
improve the design.

4.1.2  What's needed before you can do a walkthrough? 
 
You need information about four things.   (1) You need a 
description or a prototype of the interface.  It doesn't have 
to be complete, but it should be fairly detailed.  Things 
like exactly what words are in a menu can make a big 
difference.  (2) You need a task description.  The task 
should usually be one of the representative tasks you're 
using for task-centered design, or some piece of that task.  
(3)  You need a complete, written list of the actions needed 
to complete the task with the interface.  (4) You need an 
idea of who the users will be and what kind of experience 
they'll bring to the job.  This is an understanding you 
should have developed through your task and user analysis.


============================================================
HyperTopic:  Common Mistakes in Doing a Walkthrough
------------------------------------------------------------

In teaching people to use the walkthrough method, we've found 
that there are two common misunderstandings.  We'll point 
those out here, so you'll be on guard to avoid them.

First, many evaluators merge point (3) above into the 
walkthrough evaluation process.  That is, they don't know how 
to perform the task themselves, so they stumble through the 
interface trying to discover the correct sequence of actions 
-- and then they evaluate the stumbling process.

There may be times when that approach is useful, but it 
misses an important part of the walkthrough method.  In the 
walkthrough, you should START WITH A CORRECT LIST OF THE 
INDIVIDUAL ACTIONS needed to complete the given task: Click 
button "File", Type in "Smith Letter", Click button "OK," 
etc.  If you have to explore the interface to identify those 
actions, fine -- but that's not the walkthrough.  The 
walkthrough begins when you have the list of actions in hand.  
The reason for this approach is that, in the best of all 
worlds, the user should identify and perform the optimal 
action sequence.  So the walkthrough looks at exactly that 
sequence.  If the walkthrough shows that the user may have 
trouble identifying or performing one of the actions, your 
primary interest is not what the user will do when that 
problem arises -- what you really want to know is the fact 
that there is a problem here, which needs to be corrected.

The second point that many first-time users of the 
walkthrough method miss is to that the walkthrough DOES NOT 
TEST REAL USERS ON THE SYSTEM.  Of course, watching real 
users try out the interface can be a valuable approach, and 
we discuss it in detail in Chapter 5.  But the walkthrough is 
an evaluation tool that helps you and your co-workers apply 
your design expertise to the evaluation of the interface.  
Because you can imagine the behavior of entire classes of 
users, the walkthrough will often identify many more problems 
than you would find with a single, unique user in a single 
test session.

[end hypertopic]--------------------------------------------


4.1.3  What should you look for during the walkthrough?

You've defined the task, the users, the interface, and the 
correct action sequence.  You've gathered a group of 
designers and other interested folk together.  Now it's time 
to actually DO THE WALKTHROUGH.

In doing the walkthrough, you try to tell a story about why 
the user would select each action in the list of correct 
actions.  And you critique the story to make sure it's 
believable.  We recommend keeping four questions in mind as 
you critique the story:

1. Will users be trying to produce whatever effect the
   action has?
2. Will users see the contro