Editor: Jeff Patton

user centric

T hou g htWork s


A Conversation with Alan Cooper:
The Origin of Interaction Design
Jeff Patton


nly a handful of people have had a huge influence on modern software development, 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 today. Most notably, he introduced the use of personas to distill and make relevant information about

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 company 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, Structured Systems Group, wrote business applications. The first business app I wrote was a generalledger accounting program. I wrote it in the classical 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 really a glass teletype—but it interacted with users. It was single-user software … so it wasn’t really batch.
November/December 2008 I E E E S o f t w a r E

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 portion 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


User CentriC

I learned with that first piece of software that the paradigm didn’t fit. From then on, I began experimenting 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 interacting 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 minicomputers. 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 bowels 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 misunderstood 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 differently. Now, I do think that programmers do a lot of human-facing design that they’re not qualified for, don’t really have an interest or aptitude for, and certainly don’t have the tools training for. I think that’s a job for interaction designers. But programmers are self-confident. Programmers like me look at anything complex and say, “I can figure that out.” I think that’s what programmers do— and they do their best to solve the problem. You’re a programmer who’s made this change in thinking. What made you begin thinking differently? It depends on how honest I want to be; “I was touched by God …” [grin]. What really happened 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 software by myself. I conceived it, designed it, wrote

When you’re a consultant, it’s not just about being good; it’s about being good and being able to justify why you’re good.

it, documented it—I did it all. I was proud of that. I really like working that way. I liked no one telling 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 visualprogramming front end for Visual Basic, I designed it and coded the prototype that I sold to [Bill] Gates. But when it came to actually building 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 bigger, 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 organization 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 becoming a consultant. So I became a consultant for the first time in 1990. It was a real shock to the system. I discovered it wasn’t that difficult. And people brought interesting problems to me. When you’re a consultant, it’s not just about being 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 something 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 figure out some objective methodology that I was going 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 deliberate thought before …. Exactly. So I began to wonder, what was the system? 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.]

IEEE Soft warE

w w w. c o m p u t e r. o rg /s o f t w a re

User CentriC

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 structural view of what I was doing, and it was done before 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-

technologist’s mind to create badly behaved software, and how we can construct a business organization 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 interaction 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 lightweight. It’s the last little bit. It’s the difference between 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 settled 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 objects 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 unending 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 something, and then figuring out something else, and then figuring out how to do something else again. It’s all about creativity, and it’s all about design. It takes an enormous amount of creativity to conceive of a program, to conceive how it will behave and how it will be built, and then to actually build it. It’s “turtles all the way down” … it’s creativity all the way down.

fying vision.
■ Grammar. Communicate by combining a few

■ 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 purpose in life is to be a bridge. I’m a bridge between technology and nontechnologists. Most technologists have a single foundation, a professional moral foundation. For instance. if you have a programmer, 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

Alan Cooper’s books include About Face 3: The Essentials of Interaction Design, coauthored with Robert Reimann and David Cronin; and The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity. Alan continues to be a vocal influence on how interaction designers think and perform their work today.
Jeff Patton is an independent consultant, teacher, and agile develop-

Everything about software is about figuring out how to do something, then figuring out something else, and then figuring out how to do something else again.

ment coach. Contact him at jpatton@acm.org.

November/December 2008 I E E E S o f t w a r E

Sign up to vote on this title
UsefulNot useful