user centric
Editor: Jeff Patton ■ T hou g htWork s ■ jpatton@acm.org
A Conversation
with Alan Cooper:
The Origin of Interaction Design
Jeff Patton
O
nly a handful of people have had a huge
influence on modern software develop-
ment, and Alan Cooper is one of them. In
the world of user-centered design thinking,
Alan is responsible for many of the tenets
we use in interaction design practice to-
day. Most notably, he introduced the use of perso-
nas to distill and make relevant information about
Jeff Patton Alan Cooper
a system’s users, information we subsequently use to
drive interaction design.
I recently sat down for a phone conversation
with Alan. In this special column celebrating IEEE
Software’s 25th anniversary, I’ve extracted a por-
tion of that conversation, the part reaching back
more than 20 years. We talked about the birth of
modern microcomputer software and the arrival of
the interaction design discipline.
0 74 0 -74 5 9 / 0 8 / $ 2 5 . 0 0 © 2 0 0 8 I E E E November/December 2008 I E E E S o f t w a r E 15
Alan, when did you start developing software?
I started learning about software in the early
’70s. I got my first programming job in 1975
writing Cobol applications at a shipping com-
pany in San Francisco. I’m one of the guys who
created the Y2K bug.
That was one of the better bugs! Actually I know
of a lot of consultants who’ve really benefited from
that Y2K bug.
You’re welcome!
You’ve written a lot of commercially successful
products. Something happened along the way to
change the way you saw writing software. What
was it?
My career as a Cobol applications programmer
didn’t last long. I reentered the industry in ’76 by
founding an applications software company. There
were maybe three players back then: Gary Kildall
wrote the CP/M operating system, Bill Gates wrote
programming languages, and my company, Struc-
tured Systems Group, wrote business applications.
The first business app I wrote was a general-
ledger accounting program. I wrote it in the classi-
cal style that I had learned as a programmer in a
shipping company. It was batch-oriented and ran on
a green screen, or a forerunner of that—it was re-
ally a glass teletype—but it interacted with users. It
was single-user software … so it wasn’t really batch.
 User Centric
I learned with that first piece of software that the
paradigm didn’t fit. From then on, I began experi-
menting with this whole new idea that it’s not about
computer operators running a batch process, but
about people sitting in front of the software and in-
teracting directly.
Can you say more about the paradigm not fitting?
A lot of people had the same epiphany when they
went from mainframes to time-shares on mini-
computers. But it was really the microcomputers
that drove that into my head.
IT back then was called data processing. It
was a cost center, buried deeply within the bow-
els of the corporation. The programmers were
the most “not ready for prime time” people in
the organization. Everything they did was a cost
to the business, not revenue generating. Nothing
they did went out the front door. What they did
was requested and used by other people inside the
organization.
The microcomputer slowly started a revolution
where real people used computers. And the World
Wide Web opened that information technology
stuff, made it available to the general public. But
what’s interesting to me is there’s still a deeply held
mentality … those IT people march to the same
drummer’s beat they were marching to 30 or 35
years ago, when they were writing software for
consumption inside their own company.
Why do you think that is?
I wrote a book called The Inmates Are Running
the Asylum, and some programmers have mis-
understood that. They thought it was a critique
of programmers, not understanding that it was
homage to programmers and the wonderful ways
in which we’re unique and in which we think dif-
ferently. Now, I do think that programmers do a
When you’re lot of human-facing design that they’re not quali-
a consultant, fied for, don’t really have an interest or aptitude
for, and certainly don’t have the tools training for.
it’s not I think that’s a job for interaction designers. But
just about programmers are self-confident. Programmers like
me look at anything complex and say, “I can figure
being good; that out.” I think that’s what programmers do—
it’s about and they do their best to solve the problem.
being good and You’re a programmer who’s made this change
being able in thinking. What made you begin thinking
to justify differently?
It depends on how honest I want to be; “I was
why you’re touched by God …” [grin]. What really happened
good. is that I loved building software back in the day,
because I could be the classic hero programmer. I
went off and wrote big commercially viable soft-
ware by myself. I conceived it, designed it, wrote
16 IEEE Soft ware w w w. c o m p u t e r. o rg /s o f t w a re
it, documented it—I did it all. I was proud of that.
I really like working that way. I liked no one tell-
ing me what to do. It was very self-indulgent. The
problem is, as the computer platforms got more
and more sophisticated, it got to the point where I
could no longer do that. By the mid-1980s, it was
just too hard.
When I created Ruby, which was the visual-
programming front end for Visual Basic, I de-
signed it and coded the prototype that I sold to
[Bill] Gates. But when it came to actually build-
ing it for production, to go out the door, I hired a
small team of four really sharp guys, and we put it
together. We essentially wrote it again, and that’s
what we shipped to Microsoft. And that was
really the last product I developed because it just
became too complicated.
My appetite for software grew bigger and big-
ger, and to write a big application on the platforms
we had back then was just not really viable for one
guy to do. I found myself in kind of a bind. I was
going to have to either become part of a larger or-
ganization or let go of the implementation part of
what I did. I decided to let go of implementation
and just do the design part, which meant becom-
ing a consultant. So I became a consultant for the
first time in 1990. It was a real shock to the sys-
tem. I discovered it wasn’t that difficult. And peo-
ple brought interesting problems to me.
When you’re a consultant, it’s not just about be-
ing good; it’s about being good and being able to
justify why you’re good. A big component of that
became explaining myself. I not only needed to
come up with good designs but needed to explain
why my designs were good.
It’s a systems problem. Am I really doing some-
thing rational and predictable here, or am I just
having clever brainstorms? I decided that although
I’m clever and I do have brainstorms, it would be
much more valuable and interesting if I could fig-
ure out some objective methodology that I was go-
ing through. That would give me some leverage,
and it would be good for the world, good for the
industry.
Obviously, you’d had success before. You were
doing something on your own that had worked.
You just hadn’t given the process that much de-
liberate thought before ….
Exactly. So I began to wonder, what was the sys-
tem? I approached it first from a design principles
point of view.
Your book About Face came [out] about that time,
correct?
Hold on just a second …. [Alan rustles around his
office for a minute.]

I just found this, cleaning out the corner of my
office. I’m holding a 12-inch plastic ruler that says
“the principles of software design” and “copyright
Alan Cooper 1995.” This was really my first struc-
tural view of what I was doing, and it was done be-
fore About Face. It’s since kind of lost its emphasis
on my thinking; I’ve moved more to a process focus
than a principles focus.
Here are the six principles:
■ Efficacy. Achieve the user’s goals.
■ Conceptual integrity. Conform to a single uni-
fying vision.
■ Grammar. Communicate by combining a few
primitives.
■ Mapping. Make the control convey its use.
■ Trustworthiness. Design so that users gain con-
fidence and trust.
■ Engagement. Add the human touch.
That was really my first formal attempt to distill
what I was doing in my head. About Face tried to
take it to the next level, but still the process was
vague. It wasn’t until a couple years later that I
really took it to the next level.
All these principles remain excellent. They’re
very important, you have to follow them, and you
can see that—if you lose any one of them—the
whole thing starts to collapse.
What made these kinds of concepts bubble up?
It’s absolutely part of who I am. To me, my pur-
pose in life is to be a bridge. I’m a bridge between
technology and nontechnologists. Most technol-
ogists have a single foundation, a professional
moral foundation. For instance. if you have a pro-
grammer, his specialty—his moral foundation—
is being really technically proficient. If you have
a designer, his foundation is going to be in the
world of making things beautiful for humans—
that “Bang and Olufsen” theory of design. I have
two foundations. You can argue that each one is
half as good as if there were just one … [grin].
I’m fascinated by technology and by people, but
what’s really fascinating to me is building a bridge
between them.
I have done some really good programming in
my years. But I’ve also worked with some really
good programmers in this world. And truth be
told, I’m not that good. I was pleased to be able to
keep up with them for a lap or two, but I couldn’t
win that race. What’s of interest to me is being
able to understand what they’re doing and being
able to relay that to somebody who has no clue
what they’re doing and doesn’t really care or want
to know. My focus has been not just complaining
about bad software but to understand what’s in a
User Centric
technologist’s mind to create badly behaved soft-
ware, and how we can construct a business orga-
nization and a profession to solve that problem so
that users can get software that’s delightful.
That’s now known as a profession; that’s interac-
tion design. When did that term get coined?
The ruler that I’m holding says “the principles of
software design,” and that’s what I called myself:
a software designer. I didn’t want to say I was an
interface designer because interface design is light-
weight. It’s the last little bit. It’s the difference be-
tween being an architect and an interior designer.
One of them decides where the walls go, and the
other describes the kind of paint and drapery that
hangs on the walls. I’m totally coming at it from the
point of view of the guy who says here’s where the
wall goes and here’s where it doesn’t—not from the
point of view of decorating it. So I called it software
design to differentiate it from programming and
from interface design.
You know, I don’t actually know where the term
“interaction designer” originally came from. I’m
sure that you can find some widely divergent claims
and opinions on the World Wide “InterWeb.” I set-
tled on it by default because the other options were
either taken, compromised, or wrong.
Of course, “design” is a troublesome word because
an awful lot of people call themselves designers.
IEEE Software has a number of writers who are
going to refer to design as the relationship that ob-
jects and code modules have inside the system.
And they’re right. Welcome to the terminology
ghetto, the high-tech world we live in. The thing is,
the one thing that software can consume is an un-
ending supply of design. Software isn’t industrial.
Industry is about figuring out what to do, and then
doing it over and over again. Everything about
software is about figuring out how to do some- Everything about
thing, and then figuring out something else, and
then figuring out how to do something else again. software is
It’s all about creativity, and it’s all about design. about figuring
It takes an enormous amount of creativity to con-
ceive of a program, to conceive how it will behave
out how to do
and how it will be built, and then to actually build something, then
it. It’s “turtles all the way down” … it’s creativity
all the way down.
figuring out
something else,
and then figuring
Alan Cooper’s books include About Face 3: The Essentials of Interaction out how to do
Design, coauthored with Robert Reimann and David Cronin; and The
Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy something
and How to Restore the Sanity. Alan continues to be a vocal influence on
how interaction designers think and perform their work today. else again.
Jeff Patton is an independent consultant, teacher, and agile develop-
ment coach. Contact him at jpatton@acm.org.
November/December 2008 I E E E S o f t w a r e  17