Interview with Alan Cooper

Alan Cooper has more energy than a locomotive, and he thinks faster than a speeding bullet. He must type pretty fast too, because he’s provided us with some of the most helpful books in user interface design and yes, dare I say it, personas. Alan’s description of personas lit up our discipline like the Daily Planet building, and his ideas are still a sizzling topic of conversation. His history reads like a who’s-who of influential people and radical technologies. And now? Well, of course…he’s back into thinking lots and lots about trains, which were his very first love.

Interview Excerpts:

So when I was wandering in Zurich in 1972, I saw one of these banks with basement windows. Looking down into the basement, I remember I saw this computer. It was an IBM 360 and it had this panel covered with lights and buttons and switches and knobs. I stood there looking at it, and I said ‘I’m going to learn what all those buttons, knobs and lights are for.’ A couple of years later, I did: They are there to impress people. That’s their main role.

There are a lot of people who think that we’ll solve the problem by getting programmers to be interaction designers. I think that’s totally wrong. Why would you take perfectly good programmers and have them do anything other than programming? What you do is you have the interaction designers do interaction design.’

Full Interview:

Conducted by Tamara Adlin on September 24, 2007

Only Alan can explain Alan: “I programmed like a crazed weasel. I loved it. I took to it. It was my natural thing.”

Tamara Adlin:  Today I have the distinct pleasure of speaking with Alan Cooper, who in 1999 really shook up the field by writing The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity.He is also the founder of Cooper, originally called Cooper Interaction Design, which is a very well known and respected interaction design and user experience consultancy. When you were a kid, what fascinated you?

Allan Cooper:  Trains.

TA:  Trains? And how old were you?

AC:  Four.

TA:  How did you get interested in trains, and why did you like them?

AC:  I’ve always loved trains. I’ve been a train freak since I was a little kid, and had little wooden trains then. All my other toys were construction sets. I had blocks and girder
sets. I didn’t have Legos because we didn’t have Lego in the United States back then, but I had Lego-like things, like Erector Sets. I liked designing and building.

TA:  Did you like ripping them down too?

AC:  That doesn’t stand out in my mind. I wasn’t the guy who liked to destroy things, but I did like anything having to do with the military, which I guess involves a lot of blowing up of stuff.

TA:  It’s funny, we’re talking here at the CHI 2007 conference, and just this morning Jim Foley started his talk by saying that he’s glad to have time to play with trains. He’s starting a SIG TRAINS! You’ll have to go talk to him.

AC:  Really!?

TA: Yes, I’ve been spending a lot of time on trains lately.The reason I ask people about what fascinated them when they were young is that so many people in this field started when it didn’t exist. I find it interesting that these are people who made very creative choices in their academic life and their professional life.You actually cited an earlier age than anybody else I’ve spoken to. How did you continue to pursue whatever interested you throughout high school and college?

AC:  Well, trains have always been burbling in the background. But when I was 13 years old, I woke up one morning, literally, and knew what I wanted to do for a living.

TA:  At 13?

AC:  At 13. I had no idea up until then, and one morning it just hit me like a bolt out of the blue: I wanted to be an architect. I knew that was what I wanted; I knew it, I knew it, I knew it.

At my high school, they had two classes in architecture. I took them both as many times as I could. That’s what I wanted to do.

Interestingly, I never did go to university to study architecture like I wanted. I ended up getting seduced into the software world. But building software is just like architecture. It is the exact same thing. In fact, as an inventor and writer of software, I believe that I do more architecture than my contemporaries who went on and became actual building architects.

Very few actual building architects these days can actually conceive of entire buildings and then see them realized. And yet it’s possible to conceive of an entire piece of software and see it realized; it is very much an architectural process.

I think architecture is a craft, and it is an interesting craft in that it combines deeply technical stuff with an aesthetic sense and a purposeful human side. Architecture without the humans is engineering. Buildings do need to be engineered, but architecture is the part that says, “What’s the human problem we’re trying to solve?”

TA:  I’ve heard some people describe architecture as the design of the spaces in between, but they are really looking at the flow in the spaces.

AC:  There are fascinating parallels between building architecture and software design. Much of what we think we know about both practices is quite wrong. We build Wal-Marts and watch our cities die. We build customer relationship management software that alienates our customers. In both software and architecture the forest of what is really wanted is often hidden by the trees of technical trivia.

Software design is not pure engineering, though engineering is one of the legs of the tripod. It’s about solving human problems. You have to understand the human side of things.

So many programmers are so focused on the technical stuff. They see their role as solving the technical problem, implementing the task, or implementing the feature. This part absolutely needs to be done, but it needs to be done under the umbrella of what the human user is trying to accomplish.

TA:  You are defining architecture as envisioning an entire thing before you start working on the pieces. It’s also about looking at something holistically; never as just bricks or just girders or just space.

AC:  Right. In architecture, what you do is determined by what needs to be done, and then you marshal the appropriate technology to do it. Whereas the classic high-tech imperative is, “Invent a new technology and race headlong to market with it in the blind faith that the public will find a use for it.”

TA:  Okay. Let’s skip back to high school. You were doing architecture stuff. I’m not going to be so bold as to ask you what year it was, but were there computers around? Were you starting to get some exposure to that?

AC:  There were computers around, but not in high schools. Computers were only in businesses or research labs, and cost many millions of dollars. I was in the class of 1969.

TA:  Was this in California?

AC:  Yes. I had a hard time at school. I just didn’t work well in school, so I went out on my own. I was in Zurich one day, and I was wandering around and saw a computer in the basement of a bank. This was back in the days when computer rooms had windows. After all the riots in the ’70s they stopped putting windows in the computer rooms.

TA:  You’re going to have to tell me about that.

AC:  Well, in Berkeley, right across the bay here, there was a Bank of America on Shattuck Avenue. It was a classic architectural thing from the ’60s, so it had this fake stone on the outside and a basement floor that extended up above the sidewalk level by about 18 inches or so. It had little strip windows so daylight would go into the basement. You could walk along the sidewalk and look up into the main floor of the bank, or down into the computer room in the basement. Basements became computer rooms in hundreds, probably thousands of office buildings all across the country.

In the early ’70s there were a lot of riots around the country. There were all these free speech riots in Berkeley, when students would go rampaging through the streets. I happened to be one of those – I wasn’t a student at the time, I was a drop in, an outside agitator – but I would come to town. I was a nice guy; I didn’t go breaking windows and stuff. I would hang out for the excitement and to try to meet women.

But rocks and bricks and stuff did get thrown through these windows, and these very expensive computers in the basement would get trashed.

TA:  This was a common problem for early computer systems? Riots?

AC:  Yes. It was a late ’60s and early ’70s phenomenon in urban America. If you go to Shattuck Avenue today and go find that bank, you will see that where there used to be windows looking into the basement, there are now concrete and brick walls.

So when I was wandering in Zurich in 1972, looking down into the basement of some bank, I saw an old IBM 360. It had this panel covered with lights and buttons and switches and knobs. I was very impressed. I stood there looking at it, and I said, “I’m going to learn what all those buttons, knobs and lights are for.”

A couple of years later, I did: They are there to impress people. That’s their main role.

TA:  So you got mesmerized through a window of a bank.

AC:  I did. I came home from Europe. I was bumming around Europe trying to find myself -

TA:  – as one does -

AC:  – and that was one of the things I found.

When I came home, I enrolled in a community college and took a class in programming. Within a few weeks I discovered that programming was the magical wonderful place where you could build structures of magnificent scope and complexity and interest, and you had absolute control over them. You could do it all by yourself. You were in your own private universe where you could create your own private world. I was utterly seduced by it.

TA:  You took to it like a fish to water.

AC:  I programmed like a crazed weasel. I loved it. It was my natural thing.

TA:  That is so interesting because you said you didn’t do well with the whole school thing, and here you went away to Europe, came back, and dove into one of the most mathematical, challenging, and logical things you could.

AC:  It’s not very mathematical, but it is logical, and complex; yes. But the logic of it made perfect sense to me. Computers were beautiful. Software was beautiful. Interestingly, I still wanted to be an architect.

I took the introductory programming class because I thought it would be a good way for me to work part time to make enough money to pay my way through architecture school. That’s what I expected to do, and that’s how I saw it.

I just kind of got sucked into this whole programming thing. A friend of mine, who was actually a programmer at the time, said, “You should go out and work. You’re a better programmer than most of the guys I work with.” I said I’d give that a try.

So I went out and got a job programming.

TA:  Where?

AC:  I was working for a shipping company in San Francisco called American President Lines. I had hair down to my waist. I wore ties -

TA:  Please refer to the picture of Alan Cooper at the top of this page…

[laughter]

AC:  I wore a couple of ties I had gotten from the Salvation Army, and I lived a very counter-culture life. But it was great, too. It was very much the early days of computer programming – business data processing, they called it – in the business world. They didn’t know who would work these machines.

People would say, “We gotta get one of them there computers to do our accounts receivable,” so they’d go buy the computer, then they’d go to the accounts receivable accountants and say, “You guys are accounts receivable, program this computer.”

They discovered that accounts receivable clerks didn’t know how to program computers. It turned out programming was a specialty in and of itself. Then there arose the nasty question of how you identify who could be a programmer. They would have chess contests, IQ contests… It was a real problem.

We have a similar problem today. People ask me, “How do you identify an interaction designer?”

TA:  It’s a total parallel.

AC:  Exactly. How do you identify a programmer today? Well, they self-select. A programmer is a programmer; that’s how you identify programmers.

TA:  And they start out with pony tails.

AC:  Yes. So I was working with a bunch of guys who were one step removed from accountants. They were programmers, but several of them had backgrounds in the shipping business, which was interesting to see.

I was the most junior guy with the longest hair, and I was handed the cheesiest module of COBOL code that had ever been written and told to do something with it.

I started spelunking in this spaghetti code. It was the worst stuff in the world.

TA:  Was it for accounting purposes?

AC:  It was an interesting program. It was called “Cargo Handling Standard Costing System.”

American President Lines had a fleet of 22 steam ships they’d send all around the world. They would sail for a month or more between ports, and when they’d get to a port they would pull in, unload cargo, and load up new cargo. Then they would sail on.

Six months later, the bill for stevedoring in Jakarta or Singapore or Rangoon or wherever they did this cargo handling would show up back at headquarters in San Francisco. But the cost was incurred at the time of offloading, so they needed to get that information to their accountants sooner.

The port master would telegraph a scratch total from Jakarta or Rangoon or wherever. It would say we unloaded 150 tons and we loaded 200 tons.

This program said, “We don’t know exactly how much it costs to unload a ton, but based on the exchange rates and what it cost last time, I know it’s approximately $8/ton.” It gave the accountants an interim number to work from so they could get an estimated cost of doing business that was reasonably current, knowing that they’d have to make an adjustment six months later when the actual bill showed up.

TA:  That’s actually a great job for a computer.

AC:  Perfect job for a computer. This program, which was not terribly important in the grand scheme of things, ran on the computer. Keep in mind that the mainframe they had there, a 370-135, occupied a room about as big as the one we’re in now, which is probably 60 feet long and 30 feet wide. It had a giant air conditioning system and two full-time guys to stand around and take care of it. It probably had less computing power than your iPod and it cost $2 million. It ran 24 hours a day on three shifts to do all the calculating the shipping company needed.

The program ran for four hours a day. It actually used the entire mainframe for four hours a day.

So one day spelunking through this program, I came across this tyromistake where the programmer who had written it -

TA:  A what mistake?

AC:  A beginner’s mistake. He left a read statement inside a loop.

Basically, his code unnecessarily re-read every record as many as 1,000 times. I saw this and said, “This doesn’t look right,” and I spent a couple of days poking around to make sure there wasn’t anything hidden going on. I finally commented out one line of code – the one redundant read – and ran the program the next day. It took four minutes to run and it worked perfectly.

TA:  Talk about ROI.

AC:  I became the hero of the place. It was great. That was how I made my bones in American President Lines: One line of code.

TA:  So this was in –

AC:  In 1973.

TA: So you’ve made a gigantic mark by commenting out one line of code. Did you stay there for a while after that?

AC:  No. It was a huge mark in an absolutely tiny, tiny little backwater place. I was a junior programmer, and an applications programmer.

There’s always been this hierarchy in the programming world. The systems programmers who deal close to the metal with pure algorithms always look down on the applications guys.

At the time, I had a friend who was a brilliant systems programmer; one of the smartest guys I’ve ever met. We decided to start our own company.

TA:  Was that right after the shipping company?

AC:  Yes.

TA:  That’s fast for a person to go into business for himself.

AC:  We didn’t know any better. We used to get together at night, drink red wine and talk about how we were going to take over the world. We sat around complaining about mismanagement because there was quite a bit of it.

In 1975 he went traveling, and while he was gone I found this ad for a microcomputer – they didn’t call them personal computers back then. The very first microcomputer was an Altair.

[caption id="" align="alignnone" width="430"] The Altair 8800 on the cover of Popular Electronics (Source: http://www.computermuseum.li/Testpage/POP-ELEC-Altair-Jan75.jpg)[/caption]

When my friend came home from his travels, I showed him the ad and said, “Look at this, you can buy your own computer.” He looked at it and said, “What we should do is find some accountant who is ready to spend $20,000 to buy a minicomputer accounting system and instead charge him $10,000, take the money, go write one of these accounting systems, and give it to him. Then we can keep the software and go buy another computer, and we’d have a business.”

I said, “You know, it’s funny, I was at a party the other day and I was talking to a guy who’s an accountant, and he was just about to buy one of these minicomputer systems.”

He said, “Go talk to him. Let’s see if we can do this.”

So I went and talked to this accountant and he said, “Actually, that sounds like a good idea,” and he said he would do it.

My partner and I each ponied up some money, $7,000 each. We bought a computer and used that money to keep our company going while we sat down and wrote a general ledger accounting system.

TA:  How much did the computer cost?

AC:  It was about $3,000.

TA:  In 1975 money?

AC:  Yes. Computers have always cost about $3,000. Every year they doubled in capacity and power, but the price stayed the same up until just a few years ago.

The first computer we bought had 48K of main memory and two floppy drives. They were for 8″ floppies – not 5″, but 8″ floppies – and they had 170K of storage. Not meg, not gig. K.

An 8″ floppy disk (Source: http://www.flickr.com/photos/yaal/162100723/)

TA:  What language did you program them in?

AC:  That was the problem. There wasn’t a language. There really wasn’t an operating system either. We had to go around and look to see if we could find an operating system. We finally found both in the same place, interestingly enough.

We met this guy named Gary Kildall, who was a professor at the Naval Postgraduate School in Monterey, California. Gary Kildall was one of those incredibly brilliant guys who is very much one of the fathers of our industry, and is kind of an unsung hero, I think.

Gary had been doing some consulting work for Intel, who at the time was making the only microprocessor out there – the 8080. He had written an operating system for them called CP/M, and one of his graduate students, a young naval officer named Gordon Eubanks, had written a basic language compiler for his master’s thesis. We took the operating system and got it to work. It was about as primitive as you could get, but it was actually more powerful in some ways than what you could get from IBM in those days.

The language didn’t have decimal arithmetic in it – try writing an accounting program without decimal arithmetic! The integer arithmetic it had was 8-bit, so you could only have integers as high as 32,767. Again, you have an issue there.

TA:  You can just tell the accountants to divide everything by 100 and then –

AC:  That’s exactly what we did.

TA:  No!

AC:  We divided every number by 32,000, and we tracked every number in a high and a low value. So we did all our calculations separately. In the end we’d combine them and output them as the two halves of the numbers.

TA:  Okay, now you’re getting too mathy.

AC:  No, it’s really simple. It’s just like if you had to deal with the number 100,000 and did all your calculations on the hundreds and then on the thousands, and print them out together at the end. That’s what we did. It was about as primitive as you could get.

TA:  Did the accountant like it?

AC:  Yes, he did. I ran into him somewhere recently, and I said, “If you still have that old computer somewhere around, I’d love to have it.” He said, “We should have the last client off of it in a few months.”

TA:  So let’s talk more about your applications software company,Structured Systems Group, which was really big in the late ’70s. You saw Bill Gates at conferences, and you guys were heavy duty into the world of coding.

AC:  In ’78 or so, I wrote a little parameter-based database report generator program.

It was a first attempt to try to make some sort of a user-programmable, configurable program for accountants. I was learning a lot at the time and was really focused on this interface issue.

TA:  Were people starting to talk about “interfaces” in the computing industry yet?

AC:  Yes, but it didn’t have a name. Nobody really knew what it was. I assume in universities people were talking about human computer interaction because there was the odd textbook, but we were down in the trenches building software. It was very pragmatic and very commercial, what we were doing.

Our approach to this was not at all research based. There was no theory behind it. We were just building stuff, very much like the early days of the web. People just slung stuff up on the web to see what happened, and that’s what we were doing. A whole other decade passed before I began to focus on design as a distinct activity.

TA:  Tell me about when that changed.

AC:  In 1980, I sold my interest in Structured Systems Group to my partner and moved on.

About that time, I had the same sort of life changing event that Bill Gates and Steve Jobs did – I visited Xerox PARC.

I saw the Alto, and I went home and changed the way I did software.

TA:  Why?

AC:  I saw mice and menus and windows and the idea of pointing at things.

TA:  You went home, and it wasn’t all green text on black screen in your head anymore.

AC:  Right. It really changed my thinking.

I spent the ’80s building software and selling it to publishers. I did some word processing software; I created one of the very first spreadsheets. It was quite advanced for its time.

Then I wrote a serial communications program and sold it to a publisher. After that I wrote a critical path project management program, which I sold to CA (Computer Associates). That became SuperProject. It was kind of the model for Microsoft Project.

TA:  What year are we up to now?

AC:  That was in ’84.

TA:  You just kept cranking out stuff.

AC:  That was what I wanted to do. You see in the ’70s, when I started my first company, I did it all. I invented the product, I designed it, I built it, I marketed it, I sold it, I wrote the manuals and drove home from the printer with a station wagon loaded with manuals. Then I mailed them out to people. I literally did everything. It was a real startup business.

I began to narrow the wedge of the pie that I worked on as I went. In the ’80s, I decided I just wanted to invent software; I didn’t want to do any of the publishing or production stuff. I would come up with an idea and sit down and build a prototype. Then I would take it to a publisher and say, “Look at this prototype,” and hopefully they would say, “I like this. Now let’s sign a contract and you go build this and we’ll publish it and move on.”

Keep in mind that in the ’80s there were literally hundreds of software publishers out there, and Microsoft just one of many. I had sold the project management program to Computer Associates, having written 100% of it myself. It was all my code. It was pretty cool, actually. At the time, there was nothing quite like it. There were programs that did critical path project management, but you had to enter long tables.

My program would draw a picture of your critical path on the screen or on paper. Because I “got religion” from Xerox PARC, I did this on the green screen, before mice. You hit a function button and a box would appear, and then you’d hit arrow buttons to move it around on the screen. Then you could enter two numbers and tie the box to another box, establishing a critical path dependency. Then it would do its critical path calculations. It was a fairly cool program.

TA:  It was sort of a GUI.

AC:  Yes. It was a GUI on a green screen. It had low resolution graphics, but it worked.

TA:  It makes me think of PONG.

AC:  It was a lot like PONG, yes, but it worked, and you could do very sophisticated project management with it. I sold that to CA. Then I said goodbye and went off and started working on the next thing.

I did a geographical information system, which was like Google Maps except I was using DIME files, which were the then-current geographical files that things like Google Maps and Google Earth are dealing with today. They didn’t have satellites going around taking pictures, or at least they certainly didn’t publish them at the time.

What you could get were line outlines of counties, so I began working with that.

This was a classic example of a product I invented but couldn’t sell. One of the reasons I couldn’t sell it was because, in order for it to do what I wanted it to do, I needed a real graphics application environment and nothing like that existed at the time. So I wrote my own.

That’s being a glutton for punishment. It was really kind of stupid. A friend of mine grabbed me, and literally, physically dragged me to a presentation of Microsoft Windows Version 1 somewhere in Santa Clara. He said, “This is what you want.”

I saw the presentation and said, “Yes, that’s what I’ve been working on; that’s what I need.” I’d much rather buy it from Microsoft than try to write it myself, because I was struggling as a one man band. I literally was at home trying to write Windows by myself.

I became an early adopter of Windows as an applications developer.

TA:  Still in the ’80s?

AC:  Yes. This was in ’86.

I started noodling with various pieces of software. I forget what I was working on, but one thing that just leapt out at me and probably anybody who used Windows at the time was “Holy shit, this thing is so much more powerful than MS-DOS – but it has a terrible user shell.” It was terrible.

You could write an application that behaved nicely, but if you were a user and you wanted to look in your directory to see what files you had, you had to use a Windows program that was stupider than anything that existed on MS-DOS.

It was obvious to everybody that the Windows shell sucked. They knew they had to do something about it, but it was a tough nut to crack. In my spare time I would noodle on ideas for something to replace the shell.

It was a tough problem. It’s like the Mac Finder or the Windows desktop interface – it didn’t really exist at the time. What should it be? Nobody was really sure.

One day, a friend of mine had taken me on a sales call to a client site at Bank of America. I met this IT guy at the bank headquarters who was talking about his problems fielding Windows to his 30,000 employees.

The problem was that some of his employees were high-level analysts who knew how to use computers and used them regularly; some of his employees were mid-level bank people who knew how to use computers, but that wasn’t a primary part of their job; and a lot of his employees were tellers with a high school diploma. They needed to be given a carefully delineated playground in which to work.

All of a sudden I had a flash of insight. I saw that the solution to the shell was to provide a “construction set” allowing people to build their own shells. The analysts could build the shell to run their sophisticated stuff. The mid-level managers could have a shell that hides all the complexity. The analysts could also build very simple, tightly bound shells for their tellers.

TA:  Are you talking about different user interfaces?

AC:  Yes; and you build them yourself out of a construction set of widgets. That day I went home, started programming, and started inventing this thing as I went. It was basically a floating menu. On that menu was a push button, a list box, a check box, a radio button – all the familiar Windows controls.

You could open up a window, go up to this little palette of widgets, click on a picture of a menu button, drag it down and drop it onto the window, and a new, working button would appear in the window. Then you could go up and drag a text box and drop it on the window and then right click on the button and drag a rubber band over to the text box, release, and it would now wire the push button to the text box.

Then you could push the push button, and it would send a piece of text over to the text box.

TA:  These were end users who would have to stick these things together, right?

AC:  Right. There weren’t a lot of people out there doing word processing for fun. Computers were still things that people bought for offices.

The idea was that you could visually program your own shell. For example, at the time, OS/2 was out there, and it was the dominant operating system. It had a shell. With this functionality you could recreate the OS/2 shell in Windows in about ten minutes.

It was a powerful thing. It was the first Windows app that had drag and drop. I also did things so that it would fully animate when you dragged stuff. Nobody had ever seen animation on the Windows screen before.

If you were the bank teller, you could have a screen that would have three buttons for the three applications you normally ran.

If you were the mid-level manager, you could have buttons that would launch stuff, and a little directory showing you only the files that you worked on.

If you were an analyst – if you were developing these systems at the higher level – you could have it be one way on Monday and then change it around as you were working so that it was a completely different user shell on Tuesday.

TA:  You’ve been telling me all these stories about coding, but now you are suddenly talking about what you were building in a completely different way. You discovered that the core element is really who is going to be using the software.

AC:  I’d have to say I started thinking about who’s going to be doing things with software a bit earlier, when I started work on the critical path stuff in SuperProject. I talked to a few people in the field: I basically went around asking people, “Do you know anything about project management?”

I had no formal methods. I was just asking people I ran into in my daily life. I ended up talking with Kathy Lee, a woman who was a traffic manager at an advertising agency, and I based a lot of my work on her.

It was kind of a humbling thing because in the end she found the program to be unusable. I was really learning the hard way, but the good thing is I found myself saying, “What would Kathy do? What does she want here?”

This was the beginning of the idea of personas. I did make the mistake of trying to design for Kathy Lee, although I have to say I kind of abstracted Kathy Lee, so that she became a persona in my mind.

There is enough of a programmer in me to not actually want to talk to users, and to find talking to users to be an ordeal.

TA:  You were down in the weeds and actually writing the code.

AC:  Yes. I did the same thing when I wrote this program called Tripod – that’s the shell construction set I was talking about earlier. It was designed for the guy I had talked to who was the IT manager at Bank of America, and with the understanding he would have three levels of users.

Each of those obviously would be a persona role.

TA:  How did it do?

AC:  I tried to sell it, but it was just one of those products – kind of brilliant, but nobody could quite figure out what to do with it. I showed it to quite a few people in the industry, including big companies like Lotus, and they said, “Boy, this is really neat, why don’t you sell it to Microsoft as a shell?”

I didn’t know Bill Gates well enough at that point to call him up and say, “Take a look at this,” but I had some friends at Microsoft and asked them if they could get me in to see him. So we got invited in by one of his lieutenants.

This guy said, “Come on up; I’ll take a look at what you’ve got.” So I went to Seattle and met this guy. I forget his name, but it was just the two of us sitting in a conference room, and I whipped out my computer and started demonstrating the software.

He looked at it for about three minutes, pushed his chair back and said, “Bill’s got to see this.”

TA:  Nice.

AC:  So we set up a time to see Bill and I came back up to Seattle to demo my program. When I showed my dragging animation on the screen, Gates looked at me and said, “How did you do that?” He’d never seen animation on a Windows screen before. I said, “Magic.” What else are you going to say?

I continued demoing this to him, and he turned to the group of people and said, ‘why don’t we do stuff like this?’ I thought this was good.

At one point Tandy Trower, one of the guys in the room, said, “Why would anybody want this? What’s the point of this?” I was inhaling, ready to give him my pitch, when Bill turned around and started explaining why people would want this program. Then he turned to me and said, “We want to buy this. This is going to change how people work with computers.”

TA:  I don’t think he could say anything better to somebody demoing.

AC:  I thought it was pretty good. He then handed us over to the Windows team. At the time, Presentation Manager was the bull goose loony, and Windows was not seen as a strategically valuable piece of software.

TA:  When was this again?

AC:  March of 1988 is when I demoed Tripod to Bill. Microsoft was still hooked symbiotically to IBM. There was a huge political bout because one of the things my program could do was recreate the OS/2 Presentation Manager, as I mentioned. I showed it right in front of the Microsoft people: “Watch, I’ll build the OS/2 Presentation Manager (drag, drag, drag, boom)!”

Well, if you are a Product Manager on OS 2, this is going to piss you off.

TA:  Did they buy the product?

AC:  Yes; they bought the product. I proceeded to write a spec that Gates said was the best spec he’d ever seen, and they put a Microsoft QA team on the project with us.

As soon as we did the deal we changed the name from Tripod to Ruby, because I had shown it to Lotus and a bunch of other companies. It was just a random project name. Now there’s a language called Ruby , but back then it was our code name.

We worked on it for a year. I put a team together, we built a program, and we went through a full QA cycle and delivered it to Microsoft. During that time Microsoft split from IBM, and bye went OS/2, but not before the OS/2 people sank Ruby because it could recreate what they were doing.

TA:  You spent a year on Ruby, and then there was a day you found out it wasn’t going to be.

AC:  Yes. They accepted it, they paid us our last payment, said thank you, and then it never came out the door.

TA:  This hit you like a ton of bricks.

AC:  It was tough. It was a difficult time in my life because I’d told people I just sold core technology to Microsoft, but then it didn’t get released and nobody knew what it was because it was top secret.

One of the things I had done was to tell the Windows guys I was throwing Tripod out and starting from scratch, which is the right way to build software.

They went ballistic. They said, “You’re doing what? You’re throwing out code? You’re going to be late. You’ll delay us all.”

Of course it turned out they were late and I was on time because I threw the code away. What’s valuable is what you know, not what you’ve written. These are classic modern programming techniques that Microsoft hadn’t figured out at that point, or at least not on the Windows team.

TA:  What happened next?

AC:  It was a year and a half or so. I began to hear rumors that they had turned Ruby over to the languages department, and they were going to addQuickBASIC to what I had written.

I’ve never been a big fan of BASIC. It’s a fine language for writing a hundred-line program, but it’s no good for writing big software. I found it embarrassing that any work of mine would be associated with the language.

But at the time, Turbo Pascal was just chewing up the languages.

QuickBASIC, which was Bill’s product, was a dead product because it had been conquered by Pascal and C. C was for professionals and Pascal was for amateurs.

I had written Ruby in C; it was my language of choice. It was a very powerful language, but it was like a knife with no handle. You could really hurt yourself if you didn’t know what you were doing. You had to be good.

Bill had his people take my visual programming front end, unplug my little language, plug in QuickBASIC, and thus was born Visual Basic. So I like to say I did the Visual and they did the Basic.

At that time, Microsoft was growing and people would work on a project for three or four months then move somewhere else. Nobody knew who I was or what was going on. All they knew was that here was a project, here was a bunch of code, and it moved around. One person somehow heard some rumors and ended up inviting me to the product roll-out.

I went up to Washington when they did the product roll-out. I was really kind of steamed when I saw it, but I bit my tongue and said good work.

Microsoft had taken my shell ideas and turned them entirely towards programmers. Ruby had been the very first application to deliver practical use of the Dynamic Link Library (DLL) facility in Windows. Not only did the program present functionality visually, but independent, third-party vendors could create functionality that would dynamically become a seamless part of the development system. At the time it was called the VBX interface, and it was an original invention of mine. VBX has morphed into OCX and ActiveX, but it has been the platform of choice for thousands of independent programmers.

TA:  Was this early ’90s now?

AC:  Yes; it was probably 1991 when Visual Basic 1.0 came out.

TA:  Let’s skip ahead to when you recovered from all this.

AC:  [laughs] Well, this friend of mine, Mitch Waite, who fell in love with Visual Basic when he first saw it, ended up writing the very first Visual Basic book called the Visual Basic How To.

He had seen my name in the “About” box in VB, so he called me up and said, “I’ve been using Visual Basic and I see it says Cooper. Is that you?” I said, “Yeah; that’s me.” He said, “Oh, God, you have to tell me the story.”

So we had lunch, I told this long story, and at the end of it he sat there with his jaw hanging on the ground, saying, “You’re the father of Visual Basic.”

I said, “Thank you.” He had just given me my one-line resume. When I call myself “the father of Visual Basic,” I’m quoting Mitch Waite.

At that point, the industry was consolidating. When I started work on it, there were at least 100 software publishers out there. By the time I was done, there was Microsoft and that was about it. Nobody really published software that they bought from outside. They either bought companies or rebuilt their own.

TA:  So you came out of this in the early ’90s needing to figure out a different way to do things.

AC:  Yes. I wanted to write software, but to write software you needed to be a big company and have a big team, and I didn’t have that. I wanted to work on big software but I wanted to work alone.

There was no solution to it. My wife asked me, “What is it you really want to do?” and I said, “I just want to design software but I don’t want to build it.” She said, “well, do that.” It stopped me. I didn’t know how I could possibly do that.

I thought being a consultant and working on other peoples’ software would be really stupid. I really thought there were two kinds of software: my software and bad software. It was the typical programmer’s arrogant approach to the world. But I said “Okay, I’ll give this a try.”

One day in 1992, I was hosing a panel discussion at a Windows conference in Boston. At the end of it, I turned to my panelists and said, “Hey you guys, I’m a consultant. You’re going to hire me.”

Two of them actually hired me. It was amazing. One of them was a short term deal, although he ended up coming back five, six years later and hiring me again. The other guy I teamed up with, John Zicker, turned into a long term consulting relationship. I helped him as he migrated through three separate companies that he started, grew, and sold.

TA:  Was this the birth of Cooper?

AC:  This was the birth of Cooper. I worked as a consultant by myself, doing purely design consulting. I did PowerPoint presentations and sketches for my clients for two years.

TA:  Design of architectures for interfaces.

AC:  Yes. At the end of two years, I was busy all the time as a consultant. I went to my wife, and said, “I want you to come with me as I do my rounds today. I think we have something here.”

She saw the enthusiastic reception I was getting as people listened to what I had to say, and said, “I agree with you; I think there is something here.” We decided to make a business; not just with me consulting, but to really make a business. That was in 1994. We hired our first employee, Wayne Greenwood, and we became Cooper Interaction Design.


TA:  You had to figure out a way to productize yourself.


AC:  Yes. We got a new office, and one of the rooms was called the yelling room because Wayne and I would go into it and yell at each other: “No, that’s wrong,” the way programmers do. We really started to hammer out this methodology.

I was working on a project John Zicker. That guy is brilliant and all the people who work for him are brilliant. They had a brilliant product.

It was one of the very first business intelligence programs; though it was before the name “business intelligence” had been invented. This product that would go into databases and suck out their marrow and put really cool information up on the screen that you could then massage in a bunch of different ways.

It was incredibly powerful. It was a classic software tool in that it could morph into anything you’d want. I’d sit down with John and say, “Who would use this tool?” and he would skitter allover the place. Anybody could use it for anything.

I couldn’t pin it down to who would use it for what, and was craving one real world example so I could sink my teeth into this thing. Finally, I said, “I need to talk to some of your clients,” because I was in this circular discussion and it went nowhere.

John let me have access to some of his clients, but I took along his director of marketing because they wouldn’t let me talk to them by myself. And this is how I went out and started doing some of my first client visits. I’m not a scientist – I don’t do research – but I just went in and said, “What do you do? What are the issues?” and I started listening.

The patterns leaped out at me. It was obvious within six or eight interviews exactly what was going on. Coincidentally, the patterns were very similar to the ones that the IT manager at Bank of America had talked about. Remember, he had analysts who thought out algorithms for analysis, analysts who used them, and then technicians who did data gathering.

In these cases you want three interfaces: One for people to create the tools, one to organize the tools, and the third for people who just need to use the tools. That was how we created the first three personas. Rob, Cindy and were the very first personas.

TA:  What year was this?

AC:  This was in ’96.

TA:  Were you already working on About Face?

AC:  About Face was published in ’95. It was written before personas were an identified tool.

TA:  A book is a huge project. That’s one of the first big interface books. We just skipped over that.

AC:  That was based on the work I did from ’92-’94. It’s amazing now when I look back on it. I did so much work back then, and I learned so much, and I wrote. One of the things I learned as an author is that you have to trust yourself and empty your reservoir out. You have to take everything you know and put it down on paper, and you can’t hold back.

If you hold back and say, “I’m not going to talk about that until my next book,” your reader senses the stinginess and doesn’t like it. You have to say, “Here’s 100% of what I know,” with the faith that your reservoir will fill back up with more things to say.

TA:  And you also create some very big books which in themselves aren’t “usable,” which is something I worry about a lot.

AC:  Mea culpa. I accept that criticism. If I’d had more time, I would have made the book shorter. In many ways, the book was a polemic for interaction design as much as it was a how-to. At the time there were programmers saying, “Design, what’s that? I’m doing it. It’s got the features, so what are you talking about?” The other side was this usability school that said, “After the programmers give us the stuff, we’ll test it and tell you what works and what doesn’t.”

My point was that testing is too late. You have to do proactive design in advance. I wanted to get that idea out on paper.

TA:  Was it just to get it out, or was it to build your business – or all of the above?

AC:  It was really to get it out. I knew I had something unique that I had to talk about. I knew it would be good for the business, but the motivation was this had to be told.

TA:  You were overflowing with it.

AC:  Yes, I was. I felt hugely pregnant with this thing.

TA:  So you had this big book in ’95, and then you started getting the idea for personas, starting with the three you mentioned because, in your language, you were experiencing this horrible “elastic user” problem.

AC:  It was a classic elastic user problem.

That company – it was called ReportSmith – was wonderful to work with. They were the classic software company with brilliant software people and run by brilliant managers. They thought if it was a brilliant program filled with all this incredible power, then that’s what they had. They had the sense to see that it wasn’t working, but they didn’t really see what the problem was.

I came in and introduced the personas with PowerPoint. I said, “Here’s Cindy,” and started describing Cindy and what she needed. All of a sudden, I could see I was getting through. The programmers were sitting there saying, “Oh, well I could see how Cindy would want THAT, and how THAT other thing would just get in her way.” I began to realize that I had something very powerful here.

I knew that this was a continuation of what I was doing when I was writing SuperProject, when I based my work off of Kathy Lee, the real traffic manager I had spoken to. I used to go out for long walks and say, “What would Kathy do in this situation? I know she’d want to have this information, but not that information.” I knew I was doing the same thing here with ReportSmith, it was just an extension or abstraction of it. And for the first time, I put names and faces to it.

TA:  About Face is all about how to do interface design. And then you wrote the Inmates book, which talks about heavy-duty coding and why programmers aren’t intrinsically good at writing software that is usable.

AC:  The idea behind Inmates was to make the business case for interaction design. But I felt that what I had to do for my own credibility is to talk a little about interaction design as something more than just making people like something. I had to show there was a real process here otherwise it would have felt shallow to me, like asking people “Can’t we all just get along?”

TA:  In a way you couldn’t have planned it better to create buzz.

AC:  [laughs]

TA:  Here’s this big book, and everyone starts talking about Chapters 9, 10 and 11, at least for the practical folks. For people in the user interface field at that time, the first part of the book was really entertaining but it was preaching to the converted.

AC:  Yes.

TA:  Then this persona stuff just blew everybody up.

AC:  Well, yes. It did. It surprised me. I didn’t realize at the time – I knew personas were useful and powerful and we used them in everything we did; it was the foundation for our work. It didn’t really sink in that this would change the way other people thought.

I was thinking that this was just one of many tools we developed; other people will develop their own tools.

TA:  And it was part of your Goal-Directed Design ™ methodology?

AC:  Yes, by that time we had identified this idea of goal direction. We had dozens and dozens of tools that we thought up, and one of them was this idea that you’ve got to focus on goals, not on tasks. But programmers focus on tasks because tasks are features, and features are blocks of code.

One of the reasons we have very powerful software with lots of features and no coherence is because you don’t have to write software with coherence for it to work, but you do have to write it with features. Software is very much a representation of the way it’s built internally.

If you come at it from a user’s point of view instead, then you’re not necessarily going to organize it feature by feature. The way you get the vision to do that is through the personas. It all hangs together.

I was very pleased. Chapter 9 in Inmates was about personas, chapter 10 was about scenarios, and chapter 11 was about goals. It was very specific. What I was trying to say is that I am not just blowing smoke. That’s what I told myself as I was writing the book.

I didn’t see the book as a how-to for practitioners at all. I saw it as something to help business people see that not only is there a reason they should adopt user-centered design, but if they did they were adopting something very sophisticated and practical.

It was a very pleasant surprise to me to find that people were really understanding personas and starting to use them.

TA:  Certainly they were starting to create them.

AC:  Yes, there were a lot of people who created them but didn’t use them or understand them. A lot of people have misunderstood a lot of the things I’ve said about personas. One of the points I tried to make clear is that there is more value in the specificity of personas than there is in the accuracy of personas.

I said that a wrong persona is better than no persona. A lot of people have taken me to task for that because they think I am advocating arbitrary personas, and I’m not.

What I am saying is – and I’ve said this to guys at Microsoft – you’ve got 40 million people who use Microsoft Word and they all hate the program. What if you were to pick one representative archetype and design for that one person? Just make that one person ecstatic. If that person is at all representative, it means you’re going to have 10 million other similar people who are also ecstatic.

The end result is 10 million newly ecstatic users and 30 million users who feel the same way about it as they did before, which is a significant improvement.

TA:  Sometimes when I talk to people about designing for personas now, I say “If you’re thinking about one person, at least it’s going to make sense end to end.” If you don’t design for one person, the product is going to treat you like you’re a brilliant computer person on the first screen, and then 88 years old on the second screen. Even if you’re building something for grandmas and your persona is a professional NFL football player, you’re more likely to make something that makes sense.

AC:  There is this idea that the Volkswagen is not the car for everybody, but it’s absolutely the car for everybody. It was designed for everybody. In fact, that’s its name – Volkswagen means “the peoples car.” But what makes it a success is not that it’s a car for everybody, because it certainly isn’t.

It was a car designed for somebody who represented everybody, and that somebody was the person who couldn’t afford the big fancy giant cars. Another car that’s very successful in that way is the Porsche 911, which is again a car designed for a very, very narrow target market.

It just so happens to be a narrow target market representative of a verynarrow target market, whereas the Volkswagen was designed for a very narrow target market representative of a very large target market.

What’s interesting about the Volkswagen and the Porsche 911 is that they are both companies and brands that have stood the test of time. They are automobiles that continue to be produced today 50 to 60 years after their introduction, that are globally recognized, and that are standards upon which there have been many, many variants.

TA:  Because they solved something and they solved it well, right?

AC:  Yes. And they solved it because they were focused on a single user. That’s the power of the persona: Making one person happy is what allows you to build a globally visible brand.

TA:  I like to think the big secret of personas is that they promote laser focus inside your organization. The product is incidental to the focus.

AC:  This is exactly what I mean by the specificity being more valuable than the accuracy. If what you do is you set out to build a product for Jane Johnson, and you create a persona about Jane Johnson, and you design for that persona and you make Jane Johnson happy… Even if it turns out that Jane Johnson is the wrong persona – totally wrong – you’ll still have a success.

You may have a different market than you intended, but you’ll have a success. It is really hard to get programmers who think mathematically, to think about focusing on a single person, which is actually good.

There are a lot of people who think that we’ll solve the problem by getting programmers to be interaction designers.

I think that’s totally wrong. Why would you take perfectly good programmers and have them do anything other than programming? What you do is you have the interaction designers do interaction design.

TA:  Then you have to solve the problem of programmers and interaction designers being able to talk to each other.

AC:  Right. That is the critical problem. And as it turns out, personas happen to be the number one tool for that communication, because as soon as you say to a programmer, “I think this window should be smaller,” what goes through the programmer’s mind is, “Well, he thinks it should be smaller but I think it should be bigger, and I’m smarter than he is.” All of a sudden it becomes a competitive situation, and he’s simply not going to let you win.

TA:  They win in the end anyway because they are coding the product.

AC:  Exactly, and possession is nine tenths of the law.

So what you do is you go to the programmer, and instead of saying “I think the window should be smaller,” you say, “Jane Johnson would want a smaller window, and here’s why.”

All of a sudden it’s no longer your ego against his. Now he can say, “Oh, that’s what Jane Johnson wants; okay. I understand that.”

The persona becomes a very powerful tool for enabling communication by de-polarizing; by grounding out all of that competitive energy. That’s one of the great strengths of personas.

TA:  Yes. I think as consultants a lot of times we go in as psychologists to the organization that are stuck in that competitiveness – just like in a family.

AC:  Yes.

TA:  Your business has evolved, and you have this solid, process andAbout Face 3 has just come out…

AC:  On Friday I got the first copy.

TA:  So the company is running great, the process is working, you’ve got great clients, and you’re the caretaker of an extremely active brain. What’s it doing now?

AC:  Probably far less than it should.

But I began to have a lot of insight into how software gets built. It’s one of the side benefits of being a consultant and having hundreds of clients and thousands of engagements, and having those clients be big companies, little companies, software companies and product companies and service companies, and have them be all over the world.

You start seeing patterns, and the patterns are really clear. I began to realize that the problems we were experiencing were not problems in software design, and they were not problems in usability. The problems we were seeing over and over again were the problems in software construction.

Fifteen years ago, programmers built software without blueprints. Over the last 15 years, we’ve learned how to draw beautiful blueprints of great design and high-quality that are very communicative, very powerful, and very effective.

When you put those blueprints in front of programmers, what we’ve discovered is that the programmers don’t follow them. It’s not because they are dumb – they are anything but. A lot of it is systemic. The corporate organizations are organizations that know how to build software, but they’re not used to building software from a plan.

They are actually optimized to build software without plans, so everything about the process is based on doing something now, assuming you don’t know what’s going on tomorrow. When you have a plan you know what’s going on tomorrow, so you make different decisions.

I began to see that the problem was organizational and managerial. I began to tell my clients this. I discovered, much to my chagrin, that my clients didn’t want to hear this.

TA:  Of course not.

AC:  Because it’s not a technical thing.

TA:  It’s a threat. It’s saying there’s something systemically wrong with what you’re doing.

AC:  Right. And yet I see this as a huge opportunity, but I don’t think like a business person. I think like an inventor. When I see something that doesn’t exist, it screams opportunity with big neon lights to me. When most business people see something that doesn’t exist, they see risk, risk, risk.

After a couple of years of trying to bang this drum, I realized one of two things is true: Either I am completely full of crap, or there’s a real opportunity for me to set up a software company based on this new paradigm of software construction.

I decided I should go ahead and create a software company; it’s time for me to get back to building a software product.

TA:  Is that what’s next?

AC:  No; that’s what’s last. This was four years ago. I created a company and designed some software. I didn’t do a full design because part of the process is getting a team together and doing the design properly. I went about trying to get venture funding for this project, but I failed to raise money because you can’t fund a new process.

I couldn’t raise money because investors are business people, and they look at it from a business point of view. They’re willing to take risks, but they’re not willing to take leaps of imagination.

At that point, I said, “Okay, it’s time to build a model railroad.” So that’s what I’m doing. I’m building a model railroad.

TA:  So we’re right back to trains.

AC:  Yes. I’m working on building a re-creation of a portion of the Nickel Plate Railroad running from Lima, Ohio to Frankfort, Indiana in 1949.

This summer I’m going to be taking another trip back to the Midwest, tracing the old railroad routes, taking pictures, and doing research in historical societies. I’ll be in Indianapolis gathering information so I can come home and continue working on my model trains.

TA:  And we’re full circle. That’s probably a good place to finish up. Thank you so much. What an adventure. What a journey.