Alan Cooper

and the Goal Directed

Design Process
By Hugh Dubberly

Originally published in Gain

AIGA Journal of Design for the Network Economy
Volume 1, Number 2, 2001

Dubberly Design Office

2501 Harrison Street, #7
San Francisco, CA 94110

415 648 9799

Alan Cooper is not your typical graphic designer—he’s It is this: software does not reveal itself through external
an engineer and a card-carrying member of the AIGA. form—something mechanical devices tend to do. And in
He inhabits both worlds and has something important to software, the cost of adding one more new feature is almost
say to designers and other engineers. nothing, whereas adding features to mechanical devices
almost always increases their cost. Cooper argues that
Cooper is not one to say things softly. He’s outgoing, quick software is thus less constrained by negative feedback act-
to offer an opinion or an aphorism, and seems to like nothing ing to limit complexity than mechanical devices have been.
better than a healthy debate. His favorite topic: what’s wrong The result is pure Rube Goldberg: software with feature piled
with the software that increasingly fills our lives. upon feature. The trouble is that each incremental feature
makes a product more difficult to use. That leaves us with
Cooper has been designing software since the arrival of products that are increasingly hard to use—and with growing
personal computers more than 25 years ago. There are few frustration as we try to use them.
people who have thought as long and deeply about what
good software design is and about how to produce it. Much In the traditional software development process, lots of
of that thinking both comes from and infuses his work at people inside a company—and many times customers as
Cooper Interaction Design, the 70-person firm he founded well—ask for features. In many companies, the resulting list
and runs in Palo Alto, California. of features often becomes the de facto product plan. Pro-
grammers make this approach worse by picking or negotiat-
Cooper is surprisingly generous, even zealous, about sharing ing their way through the list, often trading time for features.
what he has learned. He lays out his beliefs in two books: In such a process, Cooper points out, it is difficult to know
About Face: The Essentials of User Interface Design [IDG when a product is complete.
Books,1995] and The Inmates Are Running the Asylum: Why
High-Tech Products Drive Us Crazy and How to Restore the The heart of the problem, he concludes, is that the people
Sanity [SAMS,1999]. In Inmates, Cooper provides a detailed responsible for developing software products don’t know
argument on the need for change. In sum, his argument is precisely what constitutes a good product. It follows that
this: they also do not know what processes lead to a good
product. In short, they are operating by trial and error, with
Computer chips are increasingly powerful, making computer outcomes like customer satisfaction achieved by little more
power less and less expensive. As a result computers are than blind luck.
being built into more and more products. And where there
are computers, there must also be software. And where there Cooper believes things don’t have to be so bad and points
is software, very often, there is user interaction. Already, it’s to the fact that the industry is young and still learning how to
difficult to find new cars, appliances, or consumer electron- make software. He sees an analogy in the language of film,
ics that do not require users to interact with software. a process of telling interesting stories with movies that was
not inherent in the invention of the movie camera. After the
So what’s the problem? appearance of cameras and projection devices, the art and
craft of filmmaking also had to be invented. Cooper believes
we’re near a similar point of invention in the process of de-
veloping software. (The parallels between movie making and
software development are striking: computer visionary Ted
Nelson has gone so far as to suggest that software develop-
ment is a branch of movie making).

2
Cooper advocates five significant changes to the conven- A persona is a composite portrait of an idealized user: a
tional methods of software development in his goal-directed single sheet of paper with name, picture, job description,
design process: goals, and often a quote. Cooper notes, “We print out copies
of the cast of characters and distribute it at every meeting. . .
1. Design first; program second. Until the user is precisely defined, the programmer can
always imagine that he is the user.”
Old way: programming began as soon as possible—applying
design at the end if at all. Or, in more progressive environ- Goals derived from the persona are the focus of Cooper’s
ments, programming and design happened concurrently. entire process. (See Diagram: Evolution of the Software
Development Process).
“The single most important process change we can make,”
Cooper says, “is to design our interactive products com- User goals inform or direct all design decisions. “Personas
pletely before any programming begins.” are the single most powerful design tool that we use. They
are the foundation for all subsequent goal-directed design.
See Diagram: Evolution of the Software Development Personas allow us to see the scope and nature of the design
Process. problem . . . [They] are the bright light under which we do
surgery.”
2. Separate responsibility for design
from responsibility for programming. Cooper’s approach differs from task-analysis-based ap-
proaches by focusing first on goals to ensure that the right
Old way: programmers made significant decisions about how tasks are identified. “Goals are not the same thing as tasks.
users interact with the software—often while in the middle of A goal is an end condition, whereas a task is an intermediate
programming. process needed to achieve the goal…. The goal is a steady
thing. The tasks are transient,” he says.
Allowing the same person to design and program creates
a conflict of interest. Programmers want the product to be Finally, Cooper suggests a new way of organizing
easy to code while designers desire to make the product the design team.
easy to use.
5. Work in teams of two:
3. Hold designers responsible designer and design communicator
for product quality and user satisfaction.
Old ways: one programmer, or one interaction designer,
Old way: management held programmers responsible for or one interaction designer and one visual designer.
product quality—since they’re the ones who made it.
Assign two people to all project teams: a designer to be re-
This point has an important corollary: The flip side of taking sponsible for the product concept and a design communica-
responsibility for product quality is receiving authority to tor (very like a writer) to be responsible for the description of
decide how the product behaves and what it looks like. That the product. (See Diagram: Designer/Design Communicator).
means management has to be clear with programmers that This pairing resembles the art director and copywriter pair-
the design spec is not merely a suggestion but rather a plan ing common in advertising, although Cooper is insistent in
they must follow. Cooper says, “The design team must have pointing out that the role of the design communicator goes
responsibility for everything that comes in contact with the beyond just writing and documentation.
user. This includes all hardware as well as software. Col-
lateral software such as install programs and supporting Where do these changes lead?
products must be considered, too.”
Cooper maintains that goal-directed design will lead to soft-
Cooper’s next point, the heart of his approach, is a new take ware products that are more powerful and more pleasurable
on an old idea: focus on the customer. to use. He outlines five major benefits:

4. Define one specific user for your product; 1) Improved product quality
then invent a persona—give that user a name 2) Reduced development time—which leads to
and an environment and derive his or her goals. reduced cost
3) Improved documentation (Reducing the complexity
Old way: managers and programmers talked about “the of the software reduces the time spent explain-
end user” without being specific—allowing the term “user” ing software problems and frees up time to explain
to stretch to fit the situation. how the software can really help users).

3
Designer/Design Communicator
The Power of Two-person Teams

Cooper organizes projects around two-person teams.

One is a designer, the other, a design communicator. This
method contrasts with the common pairing of an interaction
designer and a visual designer—a method that may diminish
the visual designer’s role.

Rather, Cooper’s approach is a true team, as in ad agencies

where it’s not always clear which team member wrote the
headline or which came up with the concept. In the end,
shared work is both more fun and also higher quality.

at Cooper Designer - D Design Communicator - DC

on the X-files Agent Mulder Agent Sculley

with a musical Composer (Rodgers) Lyricist (Hammerstein)

in a Platonic dialogue Citizen (knower of truth) Socrates (gadfly, questioner)

in an ad agency Art director (Lee Clow) Copy writer (Steve Hayden)

to fly – you need both Kite String

4
 D DC

draws writes

responsible for a description responsible for

coherence of concept of coherence of narrative
form and behavior
emphasis on brainstorming emphasis on thoroughness
and ideation and completeness of ideas

prepares presentation owns documentation

D DC

understand users have an idea understand and

articulate
(an approach solution in detail
or concept)

must bridge gap must bridge gap

5
 Originally, programmers did it all:
In the early days of the PC software industry, smart
programmers dreamed up useful software, wrote it, and
even tested it on their own. As their businesses grew, the
businesses and the programs became more complicated.

Managers brought order:

Inevitably, professional managers were brought in. Good
product managers understand the market and competitors.
They define software products by creating requirements
documents. Often, however, requirements are little more than
a list of features, and managers find themselves having to
give up features in order to meet schedules.

Testing became a separate step:

As the industry has matured, testing has become a separate
discipline and a separate step in the process. Today, it’s
common to find 1 tester for every 3 or 4 programmers. This
change illustrates that the programmer’s role is not fixed but
still evolving.

Today, common practice is to code

and design simultaneously:
In the move from command-line to graphical user interface,
designers became involved in the process—though often
only at the end. Today, common practice is for simultaneous
coding and design followed by bug and user testing and
then revision.

Cooper insists that design

precede programming:
In Cooper’s goal-directed approach to software develop-
ment, all decisions proceed from a formal definition of the
user and his or her goals. Definition of the user and user
goals is the responsibility of the designer—thus design
precedes programming.

6
Evolution of the Software Development Process

Programmers

Code/Test Ship

Managers Programmers

Initiate Code/Test Ship

Managers Programmers QA

Initiate Code Test Ship

Managers Programmers QA

Code Bug Test

Initiate Ship
Design User Test
Designers Usability Folks

Managers Designers Programmers QA

Bug Test
Initiate Design Code Ship
User Test
Usability Folks

7
Four Dimensions of Design

Cooper focuses on an area of design that traditional Within the last five years, a growing group of designers
designers do not often explore: the design of behavior. have begun to talk about behavior—the experience users
Yet, all design affects behavior: Architecture is about how have with a product. (Of course some designers such
people use spaces as much as it’s about form and light. And as Aaron Marcus and John Rheinfrank, have focused on
what would be the point of a poster if no one acted on the behavior for a long time).
information it presented?
These concerns—form, meaning, and behavior—are not
One way of making sense of the difference in focus between exclusive. Great work combines them—as Maya Lin did, for
Cooper’s work and more traditional design is through the example, in the Vietnam Veterans Memorial which is at once
lens of history. In the first half of the twentieth century, a carefully considered form, a series of layers of meaning,
designers focused primarily on form. Later, designers and a profoundly moving experience.
became increasingly concerned with meaning, for example,
product designers and architects introduced vernacular and Form, meaning, and behavior are not a closed set; already
retro forms in the 1970s; the trend continues today with we see hints of a fourth order of design (Richard Buchanan’s
retro-styled automobiles such as the PT Cruiser. phrase)—the design of possibility, opportunity, co-creation,
or collaborative systems. Again, it is not something new;
merely a new area of focus.

The Making of an Interaction Designer

Alan Cooper’s fascination with computers was first triggered Cooper borrowed $10,000 from his father (who took out a
by the flashing lights of an IBM System 360 that he saw second mortgage on the family house to provide the money)
while visiting a Zurich bank in 1972. After that encounter, he and started a company with his high school friend, Keith
enrolled in data processing classes and learned to program. Parsons. Structured Systems Group (SSG) developed and
sold turn-key accounting systems, offering both a personal
But Cooper’s interest in design predates his interest in com- computer and the software to run it at prices far below
puters. “One morning when I was 14,” he recalls, “I woke up comparable minicomputer-based systems of the day. They
with a bolt of crystal clarity and knew that I wanted to be an soon realized that they didn’t need to sell the computers and
architect . . . I read every book in my high school library on began to sell software independently, a new idea at the time.
architecture.” Architecture, urban planning, and transporta- SSG also began publishing Gordon Eubanks’ CBASIC, an
tion design remain passions, and Cooper often describes early programming language. In their book, Fire in the Valley:
software design in terms of architecture and vice-versa, “The The Making of the Personal Computer, Paul Freiberger and
architect translates the needs of the user into terms that Michael Swaine describe SSG as “one of the first companies
could be understood by the builder,” he says. to deliver business software for microcomputer . . .” and a
progenitor of the “general software company,” in its time on
Cooper applied to study architecture at UC Berkeley’s Col- a par with Microsoft and Digital Research.
lege of Environmental Design, but despite winning a full Re-
gent’s Scholarship, he never attended. Instead, after Cooper SSG grew to 25 people but after four years Cooper left. He
saw a magazine ad for the Altair, an early personal computer, formed a new company, Access Software. While at SSG
he put off college in order to start a software company, just Cooper had been the chief programmer doing much of the
as Microsoft founders Paul Allen and Bill Gates did. That was coding as well as designing the software. At Access, Coo-
in 1975, before there was a PC industry and before there was per’s role was chief designer. “If the user came in contact
a software industry. with it, I defined it.” Instead of doing the programming

8
 Form

Po
ssib
ilit
y
Meaning
r
vio
ha
Be

himself, he hired others to implement his vision of the inter- Pioneer Award on Cooper. Cooper notes that Gates also
face and left them free to organize the code as they thought gave him “a one-line resume: Father of Visual Basic.”
best. After two years with Access, Cooper joined his friend
Gordon Eubanks at Digital Research, taking a role focused While doing his speculative development work, Cooper
on design. He stayed little more than a year. Frustrated with toyed with the idea consulting. There were lots of opportuni-
the development process and priorities at Digital Research, ties to program, but he did not want to code other people’s
Cooper left to work on his own doing what he calls “specula- software designs. Instead, he wanted to design software
tive product development.” products, but he didn’t think anyone would pay him merely
for designing. Finally, in 1992, after speaking on an industry
Cooper worked on several projects including a visual panel, he took a gamble and announced that he was hence-
programming language. It enabled programmers to build forth working as a software design consultant. Two people
applications quickly and easily by clicking on file names and on the panel offered him work.
dragging them into a structure. Cooper showed his program
to Bill Gates who proceeded to buy it, replace Cooper’s In 1994, Cooper Interaction Design was busy enough to take
programming language with BASIC (a new version of what on two employees. Seven years later, it has 70 employees
had been Microsoft’s first product), and eventually publish with a range of backgrounds: technical writing, software proj-
the hybrid as Visual Basic. Visual Basic was wildly success- ect management, tech support, graphic design, the humani-
ful because it made easy what until then had been difficult. ties, physics, architecture, computer science, and industrial
Windows had previously required programmers to know C, a design. They occupy offices in two two-story buildings
demanding programming language. As Cooper explains, “Vi- located a block apart on the edge of the Stanford campus
sual Basic let’s you code without learning 600 Windows SDK and Stanford research park in Palo Alto—deep in the heart of
[Software Developer Kit] calls.” Gates showed his gratitude a Silicon Valley that desperately needs to put the user first.
by bestowing Microsoft’s Windows

9
Who Provides What to Whom
in the Software Development Process

Bottom-up output Top-down input

Senior Product (Project) Software Software Software End

Management Management Designers Programmers QA user

receive receive receive receive receive receive

Senior provide - compensation compensation compensation compensation a company that

Management stable environment stable environment stable environment stable environment can deliver products
vision of company vision of company vision of company vision of company vision of company
authority for product
goals
resources

Product (Project) provide a product that will be - vision of product vision of product vision of product vision of product
Management profitable, delivered requirements doc requirements doc requirements doc a finished product
on time and budget authority for visible authority for code authority for release
product behavior (invisible behavior) goals
goals goals resources
resources resources arbitration
arbitration arbitration

Software provide - time estimates - behavior specs behavior specs a product with a
Designers design plan finished artwork satisfying experience
behavior specs answers to questions
finished artwork

Software provide - time estimates tech opportunities - engineering spec a product that’s
Programmers engineering plan tech constraints feedback fast, efficient, and
engineering spec answers to questions (on test plan) meets behavior
finished code feedback candidate code specs
(on behavior spec) bug fixes

Software provide - time estimates feedback bug list, definition, - a product with a
QA QA plan (on behavior, and prioritization minimum of defects
tested code though this is rare)

End provide payment feedback on bugs input - - -

users input feedback
feedback (on behavior)

10
The Science of Goal-Directed Systems
By Paul Pangaro

Further study of goals might lead to software that adapts to Of course, human beings themselves are “goal-directed
the goals of individual users, learning and responding as it’s systems, and this recognition is an important step toward
used. For help in this quest, designers can turn to a branch improving the software design process. Everything that we
of science that studies goal-directed activity. design should reflect the terminology and dimensions of its
user, if that user is to clearly take action, absorb feedback,
A classic example of goal-directed activity is the steering and evaluate the discrepancy between a current and
of a ship toward a destination. The captain aims directly desired state. Because these processes are clearly iterative,
for a point on shore but is driven off-course by wind or tide. cybernetics would also counsel designers to view the
Seeing the discrepancy, the captain makes a correction end-user’s activity as essentially one of prototyping, that is,
based on the magnitude and direction of the error. Through iteratively converging on higher and higher fidelity versions of
iteration of this loop—action, feedback, evaluation, re- some ideal, final goal.
action—the holder of the goal does his best to reach the
goal. When interacting with human colleagues we must express
our goals in order to be understood and to collaborate.
In the 1940s the aptness of this example caused Norbert Cybernetics suggests that we look at software in a similar
Wiener and Arturo Rosenblueth to name a new discipline way—that we ask how software might hold representations
after it: “cybernetics,” from the Greek kybernetes or of our goals, help us reflect on them, and even participate in
“steersmanship.” [Norbert Wiener, Cybernetics: or Control their development.
and Communication in the Animal and the Machine. John
Wiley and Sons, 1948.] Cybernetics further suggests that interaction design may
come to embrace the end-user as a designer of goals, not
Cybernetics begins with the observer’s identification of a merely an achiever of them. As software better supports
“system” that uses feedback to modify actions in pursuit of users in achieving goals they have already formulated,
a goal, regardless of what materials comprise the system. designers may find ways to focus more explicitly on
Though early discussions were often about mechanistic helping the end-user who is not yet certain of an end-goal.
systems, practitioners in cybernetics—who came from Interaction design might then bear surprising results—
psychology, anthropology, mathematics, biology, physics, when the end-user can express, evaluate, and modify
and sociology—immediately understood the power of the representations of his or her goals.
“goal-directed” perspective for modeling human activities.

11
Goal Directed Design

provide input to
Users
Cooper puts user goals at the center of the software design
process. That process is part of a series of office practices
which depend on the talent and skills of designers and on Managers provide mandate to
their application of principles and patterns throughout the Primary responsibility: insure financial success
process.

This diagram shows the process proceeding in steps from

left to right. It leaves out feed-back loops and iteration which Initiate
are necessary for producing good work.

Research and Analyze Opportunities, Constraints, and Context

(focus in the first half, continuing throughout) Who will use the product?
What problem will it solve for them?

Activity: Define intent and Review what exists Discuss values, Apply ethnographic Define typical
constraints of project (e.g. documents) issues, expectations research techniques users
lead to
Result: Scope Audit Interviews Observations Personas
desired outcomes business plan management use patterns primary
time constraints marketing plan domain experts secondary
financial constraints branding strategy customers potential users supplemental
general process market research partners their activities negative
milestones product plan sales channel their environments served (indirectly)
(Scope may be competitors (This step leads to their interactions partner
loose or tight.) related technology a project mandate.) their objects (tools) customer
(aeiou framework from organizational
Rick Robinson, Sapient)

Artifact: Project Brief Summary Tapes Tapes Notes

Insights Transcripts Transcripts
Summary Summary
Insights Insights

Meetings: Briefing - Interviews Chalk talk -

(early findings)

Design Office Practices Designer Talent and Skills

The way the office is set up and run – the environment, A designer’s native abilities and background also affect
the spoken and unspoken rules – affect the work. the work. Cooper looks for people with these skills:
Cooper’s staff describes several key practices: - analytic - empathic
- goal-directed design process - conceptual - interpersonal
- collaborative environment and common purpose - visual - brainstorming
- D/DC team structure (see separate diagram) - written - imagination
- egoless design - communications
- appropriateness of assignments
- commitment to education
- commitment to enhance process
- assessment and self-assessment

12
 provide feedback on usability to
Users

provide bug reports to

Designers provide spec to Programmers provide code to QA certify product for release
Software development process
insure customer satisfaction insure performance insure reliability

Design Code Test Ship

The goal-directed design process takes place within a larger software development process.

Synthesize and Refine Form, Meaning, and Behavior

(ongoing throughout, focus in the second half) What is it?
How will it behave for users?

Deduce what Imagine a system to Tell stories about Derive components Organize the Refine details;
users want help users reach goals using the system based on users components describe models
drive*
Goals Concept Scenarios Elements Framework Spec
life problem definition day-in-the-life information objects object relationships appearance
end * spark vision definition key-path functional objects conceptual groupings language
experience inform design imperatives error control mechanisms patterns flow / behavior
motivate (May require changes set-up logic / narrative flow product character
personal filter in scope.) navigation structure product story
organize
practical prioritize
corporate inflect
false validate

Notes Formal Document Notes Lists Sketches Formal Document

Problem Statement Storyboards Sketches Flow Diagrams Demonstration
Vision Statement Diagrams Prototype
High-level data models

Chalk talk with Presentation - - Chalk talk with Presentation

management programmers

Throughout the goal-directed design process, designers apply other practices,

their talent and skills, as well as principles and patterns.

Design Principles Design Patterns

Principles guide the choices designers make as they Design patterns are recurring forms or structures which
create. Principles apply at all levels of design from broad designers may recognize or apply – during analysis and
concept to small detail. For example: especially during synthesis. Christopher Alexander,
- Do no harm. (Hippocrates) “A Pattern Language,” provides examples of patterns for
- Meet user goals. architecture; Cooper collects patterns for software
- Create the simplest complete solution. (Ockham, Fuller) interaction. For example, a common pattern is dividing a
- Create viable and feasible systems. window into two panes: the left smaller pane provides tools
or context and the right larger one provides a working
space or details.

13
How to Build a Successful Product

Underlying Cooper’s approach to design is the premise that Cooper applies this model to three software giants
products must balance business and engineering concerns who have failed to find a balance:
with user concerns.

He begins by asking, “What do people desire?” Then, Novell emphasized tech-

he asks, “Of the things people desire, what will sustain nology and gave little
a business?” And finally, he asks, “Of the things people attention to desirability.
desire that will also sustain a business, what can we build?” This made it vulnerable
A common trap is to focus primarily on technology while to competition.
loosing sight of viability and desirability.

Understanding the importance of each dimension is only the

beginning. That understanding must be turned into action. Apple emphasized desir-
We’re most familiar with this process along the business ability but has made
dimension: create a business model and then develop a many business blunders.
business plan. That process works for technology and users Never-the-less, it is
as well. Cooper’s goal-directed design process is an analog sustained by the loyalty
to the business planning process. It results in a solid user its attention to users
model and a comprehensive user plan. creates.

The user plan determines the probability that customers

will adopt a product. The business plan determines the
probability that the business can sustain itself up to and Microsoft is one of the
through launch—and that sales will actually support best run businesses
growth thereafter. And the technology plan determines ever, but it has not been
the probability that the product can be made to work and able to create highly
actually delivered. desirable products. This
provides an opening for
Multiplying these three factors determines the overall competitors.
probability that a product will be successful.
Ca
ility

pa
ab

bil
sir

ity
De

Product Art

People Technology

Architecture
Viability Design

Larry Keeley proposed the original model (above) on which Politics Engineering
this diagram (far right) builds. Keeley’s model described the
three primary qualities in a high-technology business.
Business
Others have proposed measures of quality that have
three dimensions:
- Vitruvius: solidity, commodity, delight
- ISO 9241: efficiency, effectiveness, satisfaction Cooper relables the ‘teething rings’ people, business,
- Cooper: hot, simple, deep and technology. He places his first love, architecture,
- and of course: fast, cheap, good at the center – along with software design.

14
 Probability of Probability of Probability of Overall probability
x x =
customer adoption sustaining business technical completion of product success
Th (once the product (up to launch and (delivery)
ed
om has launched) long enough after
ain
of to build revenue)
go
al-
dir
ec
User plan ted Technology
de
sig plan
n
a) design
schedule a) engineering
User model Technology schedule
b) behavior model
spec a) context b) engineering
- historical 1.) What do people 3.) What can a) technology spec
- social desire? we build? components
- economic
b) competitors
Objective:
b) user
a product that is
- demographic c) build vs buy
desirable and
- psychographic buy vs open source
viable and
- technographic
buildable

c) values

d) goals

e) scenarios
2.) What will sustain
a business?

Business model

a) funding model, b) income/expense projections, etc

Business plan

a) marketing plan, b) launch plan, c) distribution plan

15