Go behind the scenes in this two-part Masters In Conversation series with Alan Cooper, exploring the origins and applications of Goal-Directed Design (GDD). In Part 1 we rewind to the early 1970s when Alan was just starting out and the climate of programming and design was changing rapidly, forging the insights that led to the techniques of GDD. Part 2 brings us up to date with GDD as Cooper designers and teachers apply it today.
Part 1: In the Beginning…
While it’s common today in the design industry to talk about user experience, according to Cooper’s founder Alan Cooper, that wasn’t always so. When he entered the business in the 1970s, software design engineers were writing code only for other engineers. As software began to transition to personal computing, users without advanced computer science degrees were left with a decidedly poor experience, baffled and left to fend for themselves.
During this awkward stage, Alan Cooper had an insight that led to a new way to approach design, focusing on the goals of the user instead of the goals of the product. Today, designers at Cooper, the design company Alan and his wife Sue founded in 1992, apply this Goal-Directed Design method to client projects, and the Cooper U training staff shares the power of this process in courses around the world.
Recently, I had a chance to visit with Alan to discuss the origins of Goal-Directed Design and the philosophy behind it. I found him at his ranch in Petaluma, CA, in the midst of assembling a digitally enhanced chicken coop made from reclaimed Redwood.
It was heading into late afternoon as we sat down in his light-filled workshop to record this two-part conversation. The space is large, with high ceilings, and well-equipped with tools and materials for making things. Alan designed the converted workshop, which had been a dairy barn, and in his inimitable, spirited way, he shared the background that led to the invention of Goal-Directed Design.
CK: Alan, going back to when you were first getting into this field in the 1970s, what was the climate like that led to your concept of Goal-Directed Design?
AC: Well then, as now, the meaning of design to a software developer was different than the meaning for, say, an auto developer, interior designer, or someone making pharmaceuticals. To understand this difference you have to tease the concept of design apart. Most people tend to think of design as an aesthetic exercise, to make something pretty, pleasant, nice, like Martha Stewart. Understanding design in the context of function was and is a different matter; and much of my early thinking around Goal-Directed Design hinged on this.
CK: Did you have some early influences that primed you to think along these lines?
AC: Oh yes. There’s a great philosopher of design who comes from the building architecture world named Christopher Alexander. He’s fairly well known in software circles because he invented the notion of a pattern that has been widely adopted in the software development and software design world, and it is a wonderfully powerful tool for understanding things from a functional perspective.
But even before he developed the pattern language concept he had developed a philosophy of design that he wrote about in his first book, a slim little volume published in the early sixties called Notes On the Synthesis of Form, one of the most important books on design ever written, and one of those seminal texts that has influenced so many people in the design world, including me. I checked it out of the Redwood HS library when I was 14 years-old, and, you know, mind-blown. He defines design as "creating a fit for a context."
There is a context, a problem, a situation, a need, and what you have to do is come up with something, synthesize something, that satisfies that need. Well, this is a conception of design that isn’t Martha Stewart. This isn’t about what looks good, or what you like, or what comes out of your “artistic well,” it’s about what solves a problem in the real world. And it’s a completely different vision of design. And this is one of the concepts in the book that rocked my world -- you’re not making pretty pictures, you’re solving problems.
CK: It sounds like architecture really captured your interest.
AC: Oh sure. As a youth I wanted to be an architect, and I thought about problems and the philosophy of design in the context of buildings. But when I got exposed to digital computers in the early 1970s I was seduced into the amazing new power of digital computers, and I became a programmer. I just loved the medium, and I wallowed in the wonderfulness of being able to write code, and I wrote and wrote and did all kinds of things all over the map until eventually I started creating software that people actually had to use.
AC: Yep. In the early days, software was made by professionals for the use of professionals. Then as the micro-computer revolution took place, which was the tiger I was riding, my products were being used by people who weren’t trained computer professionals, and they looked at my beautiful, wonderful edifices of logic, and they said, “It’s too hard! I don’t like this!” And I went, “Wait a minute, how can you say that? It’s better, it’s more improved, it’s got good functionality, it does things that other things can’t do!”
And I had this cognitive dissonance when delivering functionality to people came face-to-face with people saying, “yeah we like the functionality and all, but it’s really a pain for us to use.” And I was even really good at explaining to them how to use it. I wrote the computer manuals, and I thought I was pretty ahead of the game with some of the innovative stuff that I was doing, but ultimately it became clear to me that it wasn’t that I wasn’t doing a good job, it was that I was not doing the right job. I realized that when your approach is to simply create functionality to bestow on the masses, it doesn’t come through, it doesn’t work, and it doesn’t satisfy.
CK: That’s a key shift in perspective. What was the general climate in software development at the time?
AC: Well, one of my favorite sayings is that you can sell dirty water in the desert, and the climate back in the early days, in the 70s and 80s, was a very dry desert. Your only choice was to use lousy software that treated you very poorly, or you could do the task by hand, which in many cases meant you couldn’t do it at all. In which case, people bought your software and used it, but there was a lot of really bad software that got sold to a lot of people who only used it because they had no alternatives, and after using it they sat quietly weeping, and fortunes were built on people weeping.
CK: Sounds painful. What sort of products were you creating in these early days?
AC: At the time when I had this epiphany that I wasn’t solving problems by doing features, my niche was business software and then productivity software. It was general ledger, accounts receivable, payroll, inventory management, basic database stuff, and that’s where I understood that you had to think differently about this. It’s one thing to say you’ve got to make a product easy to use, and another to say just exactly how you do that. One way you can make it easier is by making it less powerful, because a byproduct of making something less powerful is that it’s simpler, it’s easier. But it’s also less powerful. So the question is, how do you make it just as powerful, but still easy to use? And the answer, it turns out, is not really an engineering problem. And since most other problems in the software business are engineering problems, the industry is populated with talented engineers who, not surprisingly, try to solve each problem by engineering. But it’s not an engineering problem.
And so it’s like bringing a knife to a gunfight, it doesn’t matter how sharp the knife is, and it doesn’t matter how good your engineering skills are, you are not going to solve the problem. So the more I wrestled with this the more I began to build a lot of interesting software, and my software seemed to be pretty good. And I began to wonder how it was that I was able to create successful software, such as Super Project or Visual Basic, which, it turned out, was both powerful and easy to use.
CK: Sort of like reverse engineering your non-engineering?
AC: (Laughing) Right. And top of the list was getting into the user’s head. That was just fundamental. But that alone didn’t do it, because you can say, “Okay, I’m in their head, and what they have to do is x, y and z, so I’ll create a program that does x, y, and z” and it turns out that isn’t good enough. Because there are certain things inside their head you need to look for that give you insight into what you have to do, it’s not just about delivering functionality -- as I said, I had delivered functionality in my very early work, and they didn’t want just that.
So the essential revelation came to me that what mattered isn’t just knowing what people have to do, but answering, “what is their desired end state?” Where do they want to go? And I began to see this in terms of their goals and their motivations, breaking down the problem in order to understand it so that you can design the software to satisfy it. So it isn’t looking at what people do, but why they do it. And all of the sudden this gives you a completely different perspective. It gives you a completely different vision of how the product must behave.
CK: Can you offer an example of this thinking at work?
AC: Sure. Say the person you’re designing for wants to spend Christmas with grandma. She assumes a requirement is driving, and thus needs to pack the car, stop at the gas station, and put chains on the tires. So if you start building software to pack the car, put gas in the car and put chains on the tires that’s how you make bad software. Think about it. Packing and filling gas tanks isn’t what she wants to do, she wants to touch a picture of grandma on a screen, and boom, magically appear at grandma’s house. That’s what the persona you’re designing for wants. Okay, so then you can step back. Now that you know the desired end state, you can say, okay, I don’t in fact have brain conduction or teleportation abilities, so actually traveling there is a requirement, but now I can ask, does pumping gas and putting chains on the car put me in a direct line to getting me to grandmas? Looking at what is motivating people and what their desired end states are is much more useful than looking at what are they doing, what functionality are they marshaling, what actions are they taking. Otherwise the actions and functions will be very rational and engineering-centric, and that’s what engineering approach gets you to, the sum of all desired functionality.
CK: So this was the genesis of the Goal-Directed method -- this idea that if you look at the goals that are driving people it will give you insights into how to design that you can’t get any other way?
AC: Yes, exactly. So if you look at social media, for example, what it is, is really lousy email. And if you’re an engineer, that doesn’t make sense. Not if you look at social media as a communications problem. But if you get in the heads of social media users, you start to see a different point of view. It’s a lot like a how people view a high school reunion -- they go if things are going well, not so much if not. And if you understand social media, you see that it mirrors this. Social media is essentially about either finding dates or bragging to your peers. And with this realization all of the sudden you get what it really is.
So the key is not about the aesthetics, and it’s not about the blocking and tackling of screen design, buttons and functions, it about how do you understand what problem it is you are working on? Remember Christopher Alexander -- in his definition of design, he calls it, “synthesizing form that is a fit for context.” In other words, problem solving. And the most critical part of problem solving is knowing which problem it is you are solving. And what the Goal-Directed Design process does is provide a problem knowing process – what problem are you solving and what are the salient parts of the problem? What is really critical?
CK: Which is the perfect lead-in to discuss how Cooper is applying GDD today in Part 2 of our conversation. Thanks Alan! To be continued…