Goal-Directed Design: An Interview with Kim Goodwin

Kim Goodwin is the former General Manager and Vice President of Design at Cooper. The great folks at Cooper created an interaction design methodology known as Goal-Directed Design. Their methodology identifies the goals and behaviors of users and directly translates them into the design. UIE’s Christine Perfetti recently had the chance to talk with Kim about her work and we’ve included an excerpt of their conversation below.

[ Editor’s Note: You can hear Christine and Kim’s entire conversation in our UIE Podcast.]

UIE: Alan Cooper, the founder of Cooper, originally popularized the concept of personas. How does Cooper define a persona?

As personas have become more and more popular, many people have started to misuse them, so there are a ton of misperceptions out there about what personas really are.

A persona is a behavioral model. The most effective behavioral models are distilled from interview and observation data of real users into an archetypal description of how a particular type of person behaves and what their goals are.

The two essential components of a persona are the persona’s behaviors and goals. For any product or service, design teams have to create multiple personas that represent the range of likely behaviors and goals.

Some design teams base their personas on a real person instead of a fictitious archetype. What do you think of this approach?

Certainly there are some real people who are very similar to a persona the design team may create, but it’s a dangerous approach because real humans are idiosyncratic. For example, any individual user might hate the color blue or have some other random opinions that aren’t necessarily representative of a larger population.

One of the strength of personas is that they gloss over those little idiosyncratic things and really focus on the essence of what is common to this particular type of person. That’s one of the reasons why we rely on personas instead of real users—they are more representative.

When creating personas, you focus on up-front user research. Can you describe what this research involves?

At Cooper, we rely heavily on ethnographic techniques. We focus on the context of use, looking at how people behave in their environment, whether that’s an office or an operating room, or on the train somewhere. We can be investigating an existing version of a product, a competitive product, or even a paper and sneaker-net version of something that doesn’t exist in a digital form yet.

In our research, we focus on uncovering how people use their existing tools and what mental models people have about their tasks. We also investigate how people currently accomplish their tasks, where they experience frustrations, and where there are opportunities for improvement.

Personas are really only one aspect of Cooper’s rigorous interaction design methodology, Goal-Directed Design. Can you describe the steps involved in your methodology?

We call our methodology “Goal-Directed” because it focuses on accomplishing goals. It’s important to note that these are not only the persona’s goals but also the business’s goals. If design teams only focus on the persona’s goals to the exclusion of making profits, the product won’t be successful.

In an ideal world, we start out conducting user research in contexts where people use the product or the service. Then, we create personas based on usage patterns and the sets of goals we’ve observed. Typically, we have only a small set of personas. For a consumer web site, we have about six personas. For a complex enterprise application where there are a lot of complicated interrelated roles, we may need 20+ personas.

Next, we use the personas to drive scenarios. The persona-scenario pairing is critical because if you just have a persona, it’s like having a really interesting character, but no story to tell. Just like you won’t have a good book or movie unless there’s a story, design teams won’t get a good product design with just a persona. They have to say to themselves, “In this situation, how would this persona ideally like to experience this interaction?” and “How does that look?”

By pairing the personas with the scenarios, we gather requirements, and from those requirements, we create design solutions. To create the initial design solutions, we use scenarios to drive what functionality is available and what’s paired together. We also use design patterns and principles to help us figure out how to concretely represent that functionality. These steps all come together in what we call the interaction framework, which is the initial sketch of the design. For example, how many screens does the solution have, how do users move around the interface, and what kinds of big things does it accomplish?

From there, we again use scenarios at increasing levels of detail to refine the design and constantly iterate it all the way down to the pixel level. Of course, there’s plenty of developer collaboration, and visual design in the mix, but this is our methodology in a nutshell.

Should every feature in a Goal-Directed Design be tied to user research?

Yes and no. Every feature should be tied to research in some fashion. Most of it’s going to come from user research, but occasionally a feature is driven by something like a regulatory requirement in healthcare that may not have anything to do with a user goal but the design team must include it or the product won’t ship. So, every feature and function in the design is traceable back to something, mostly user research.

Many of our clients see the importance of creating personas. However, some teams have very limited time and resources to go out into the field and talk with their users. Do you have any recommendations for dealing with these constraints?

People often have misconceptions about the word “research.” When you start using the word “research”, people automatically start thinking months and millions of dollars, and that’s really not the case.

Design teams can conduct rigorous research for a simple product in just a matter of a few days. In many cases, teams can conduct research for a really complicated enterprise application in under a month. It’s a matter of making sure people understand the scale of effort.

When we have a really tight time frame at Cooper, our approach is to look to friends and acquaintances and say, “Can we find a handful of people who are at least something like the type of user we’re trying to recruit?”

It’s not ideal, and obviously you’ll have less confidence in what you’re designing, but three or four perspectives different from our own can still help us to see the world in different ways.

Of course, designers won’t want to base a multi-million dollar development effort on three casual user interviews with friends of friends. Even so, if the time frame is compressed and it’s the only choice the team has, it’s better than not doing anything.

In Cooper’s Goal-Directed Design methodology, what is the team composition?

Our typical design team consists of two people who form the core of the team. One is a full-time Interaction Designer who works on that project and only that project. We also have the Design Communicator, another member of the team that works full-time on the project. We invented the Design Communicator role at Cooper over a decade ago. At first we thought, “Let’s hire technical writers to document what the interaction designers are coming up with.” However, we found that if you hire the right kind of technical writers, they don’t just write down what you say, they say, “Well, why is that good? And why would you do it that way?”

We’ve found that, by hiring the right people, they were naturally inclined to help us refine the design and clarify it. They were very rigorous in making sure it was fully articulated and that we had considered everything.

The Design Communicator role has really become a design partner, and so the interaction designer and design communicator are sort of like two halves of a brain. It’s like Scully and Mulder on “The X-Files.” One says, “Well, it ought to be this way!” and the other one says, “OK, I’m not sure I buy that.”

You are presenting a new seminar for us this year, The Essentials of Interaction Design. Can you tell our readers what you’re planning to cover?

I think the UIE audience in particular has heard me talk a lot about personas and about research. This class really is not about that. It’s about what designers need to accomplish once they’ve finished the research.

The seminar will cover skill building: How do you develop your essential design skills, such as visualization? How do you get to the point where you can confidently make marks on the whiteboard and have it mean something? I’ll also cover how design teams can use scenarios, patterns, and principles to visualize and iterate solutions. My seminar is really about the design creation part of the design process.

Thanks for the time, Kim.