SpoolCast with Kim Goodwin Brian Kim Goodwin, interviewed by Christine Perfetti. Recorded at the Christiansen: studios of User Interface Engineering, July 5, 2007. [music] Welcome, I'm Brian Christiansen, producer of the SpoolCast. In today's SpoolCast, Christine Perfetti, UIE's Managing Director, sits down with Kim Goodwin, the General Manager and Vice President of Design at Cooper. Folks at Cooper are known for, among other things, two methods in the design process: Goal-directed design and personas. Kim was a major contributor in the development of both methods. Kim is also a frequent and well-respected speaker on the topic of design. We reached Kim in San Francisco by telephone. If you're interested in learning more from Kim Goodwin, be sure to attend the User Interface Conference this November in Cambridge, Massachusetts. Now in our 12th year, the UI Conference allows you four straight days of learning with some of the world's top designers, information architects and usability professionals. On Wednesday, November 7, Kim will present the full day seminar, The Essentials of Interaction Design. We hope you'll join us. And now, without further ado, here's Christine. [music] Christine Hello everyone. I want to welcome you today to this week's Perfetti: SpoolCast, UIE's weekly podcast series. I'm Christine Perfetti. Today I have Kim Goodwin here with me to participate in a quick interview. Kim will be speaking at our upcoming UI12 Conference in Cambridge this November. But I'm really happy to have a chance to snag her for a few minutes, just to talk a little bit about Kim's work at Cooper, and her thoughts on the world of design. Hi, Kim. Kim Goodwin: Hi, Christine. Thanks for having me. Christine: Thanks for chatting with us for a few minutes. Now just to give our listeners a brief background on your work, you're the Vice President of Design and the General Manager at Cooper. Here at User Interface Engineering, when we get questions from our clients about interaction design or interaction design problems, we turn them over to your organization for help. And so I'm really excited to have some time to talk with you. To get started, I wanted to talk a little about personas. Kim: OK. Christine: The reason I want to begin there is because when we talk to our clients about Cooper and the work you do, they start asking a lot of questions. Alan Cooper, the founder of your company, originally popularized the concept of personas. We've been hearing from our clients a lot of misconceptions about what a persona is, and a lot of them are saying very different things. I just want to get a brief intro from you about how Cooper defines a persona. Kim: That's a good question. I think that as personas do become more and more popular, a lot of people are misusing them, and so there are a ton of misconceptions out there. A persona is a behavioral model. In order to be most effective that behavioral model should be distilled from firsthand interview and observation data of real users. Then it should be distilled down into a description of an archetype of how a particular type of person behaves, and what their goals are. Those are really the two essential components of a persona: Behavior and goals. And for any product or service, you're going to have multiple personas. Some people wonder if one persona can work for their whole range of users, but it really doesn't. It's typically a set of personas that represent the range of likely behaviors. Christine: Right. Many of our clients have heard of Cooper's persona technique. Some of our clients have thought about creating personas around a real person, rather than having an archetypal persona. If that one real person can encompass a user group, it will be adequate for their needs. I'm curious to hear what your thoughts are on that. Kim: Well I think certainly there are real people out there who are very similar to a persona that you might create. But I think that's a little bit of a dangerous road to go down. Real humans are idiosyncratic. Any individual user might hate the color blue or some other random thing like that, which isn't necessarily representative of a large population. Part of the power 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. Christine: Right. Kim: So that's part of why we rely on personas rather than real users because they are more representative. Christine: And in terms of the work you've been doing, you talked about your upfront user research. Does most of the upfront research typically involve interviews or focus groups with users to identify what their needs are? Kim: We rely pretty heavily on ethnographic techniques. I won't say it's pure ethnography because it's adapted to our needs as designers. But what we're really doing is going into the context of use, whether that's an office, an operating room or on the train somewhere, and look at how people behave in that environment using existing tools. And that could be an existing version of the same products, a competitor's products, or it could be a paper and sneakernet version of something doesn't exist in a digital form yet. We're looking at how people are trying to accomplish those kinds of things today, where the frustrations are, the opportunities and what are the mental models we're seeing in how people think about their tasks. Christine: Recently, I read an article of yours that may have been written late last year. It was about some of the problems you've seen within organizations and how they've gone a little bit too far with incorporating personas into their development. I'm curious to hear a little bit about that. At this point, when we talk to our clients at UIE, we encourage them to use personas in any way that they think is helpful. But I'm curious to hear from you about some of the problems you've seen within organizations that may go above and beyond how they use personas. Kim: What ever works, works. If those people are having good success with something, more power to them. But what concerns me about some of what I've seen is that people get a little too enamored of the personas. They embrace them with such enthusiasm that when you have a hammer, everything starts to look like a nail. Personas are very powerful tools, but I think people start to treat them like an end in themselves. I know of one company, who shall remain nameless, that actually has a department of people dedicated to the care and feeding of their personas. Christine: Wow. Kim: This is really overkill. The personas are just a tool and they're one of many tools in a designer's toolkit. They're pretty important and we use them a heck of a lot. But if they're becoming the end in themselves, that's a problem. We tend to think of it like a gold-plated hammer. It looks pretty but it's actually much more than you need, and isn't as useful as a hammer because you've spent too much time making it too precious. So there are people who are creating literal persona living rooms and spending time updating those. What is really the return on the investment there? Christine: Right. Kim: It concerns me that people are going to be seen as things that are really just eating up resources without providing as much value. It's hard to justify the expense of creating offices for your personas and... Christine: Right. Exactly. Kim: ...you know, throwing that many people at them, and so forth. If they do them well enough that they tell the story and market them enough that you're keeping them alive, but that's enough. Christine: OK. Kim: You know? Christine: And when we talk to clients, it's interesting that you're saying so market and promote them enough that they're alive. That's even still something that are clients are grappling with all the time, that at least initially, when they're trying to get their organization to adopt these target personas, everyone is on board, but it's really hard for the team to keep these personas alive for the entire project. In your opinion, is that why many of these organizations are going above and beyond for their personas? Kim: Absolutely. Absolutely. I think that it can be tempting to do a lot of these things to market your personas, and you need to do some of them, you know. Print some t-shirts. Put some posters on the wall. That kind of thing works great. I think that if you do a good job initially and if the design team and the product management team are conscious of continually bringing the personas into conversations, it becomes unthinkable not to and you don't necessarily have to go to the extremes. One client of ours actually cracked me up. They created email addresses for the personas and they sent members of the team emails from the personas, which, I don't know, to my mind, starts to get a little creepy. "Hello. This is the persona. Have you been thinking about me today?" [laughter] Christine: Exactly. Well, I've been hearing sort of creative ways of using personas, too. I don't know if last year you were at CHI, but Jared Spool, Jared from our organization, he was at CHI in Montreal, where the folks from Yahoo were talking about persona parties that they were putting together. They were basically getting the entire development team in a room, introducing them to the personas, and then playing a little game where they were sticking stickers on the backs of the all the development team members, giving them a specific persona label. They had to start going around the room and figuring out who they were. Apparently, according to the folks at Yahoo, this is really working well as a team building exercise, but also really keeping the personas alive with folks. Kim: Yeah, and I think you have to assess your organization's culture to figure out what way of introducing the personas is going to work best. You know, certainly a culture that believes in play may find that approach really appealing and then they work very well. Other cultures that are a lot more reserved, the developers are going to look at that and say, "Great. Forced fun. Can I get back to coding now?" [laughter] Kim: So, it really depends on your organization. Christine: Right. Kim: You know, do what you need to get them introduced and to get people believing in them, but constantly reassess. You know, what's going to be the return on the effort here? Really use the personas to focus on delivering the design results, because if you don't focus on results, personas are just going to become a time waster and people are going to cease to believe in their usefulness. Christine: Right. Right. Now, it's funny. When I start talking with our clients at UIE about the work Cooper does, I mentioned everyone's mentioning personas. But personas are really only one portion of a bigger methodology that you folks have really developed and refined over the years with goal defined methodology. I think a lot of times our clients are thinking, "OK. If we go out and conduct some research and we develop these personas, then we're good to go." Without knowing as much about your rigorous methodology regarding goal directed methods, I was just curious if you could spend a couple of minutes, like a quick and dirty introduction to what your goals directed methodology at Cooper involves. Kim: Sure. Well, it's called goal directed because it's centered around accomplishing goals - not only the persona goals but also the business goals, because if you focus on the persona goals at the exclusion of making profit, your product isn't going to do so well. Essentially, we start out, in an ideal world, conducting some research in context of where people would be using the product or the service. Of course, on a compressed timeline, we may not be able to do much research. It's an ideal, not something we always get to do. Then we create personas based on usage patterns and set some goals that we've observed. Typically there's a small set of these. For a consumer website or something, maybe half a dozen. For a complex enterprise app, you might have 20 plus personas because you have a lot of complicated, interrelated roles. Then we use the personas to drive scenarios. The persona scenario pairing is really critical because if you just have a persona, it's kind of like having a really interesting character but no story to tell, and you don't get a good book or movie out of that unless there's a story. So you don't get a good product design out of just a persona. You have to be able to say, "OK. In this situation, how would this persona ideally like to experience this interaction and how does that look?" So pairing the personas with a scenario, it's how we get to requirements and how we get from requirements to design solutions. The initial creation of design solutions is really a blend of using scenarios to drive what functionality is available when, what's paired together, and so on, plus, design patterns and principals to help us figure out how to substantiate that functionality. Those three things really come together in what we call the interaction framework, which is the initial sketch of the design. How many screens does it have? How do you move around in the interface? What kind of big things does it accomplish and how? From there, we're really using scenarios again at increasing levels of detail to refine that design and constantly iterate it all the way down to the pixel level. Of course, there's plenty of developer collaboration and there's a design in the mix and so forth, but that's sort of it in a nutshell. Christine: In terms of the entire process, theoretically every feature in a goal directed design should or can be tied to user research? Kim: Yes and no. I think that every feature should be tied to research in some fashion. Most of it's going to come from user research, but occasionally it's really driven by, say, a regulatory requirement in health care that may not have anything to do with user goals, but by golly, you have to get it in there because the product won't ship without it. So every feature and function in the design is traceable back to something, mostly user research. Christine: OK. In terms of user research, one of the challenges we're hearing from design teams all the time is that clearly they all ready buy into the process that they need to understand their users. Many of our clients are all ready trying to create personas. The challenge they're having is limited time and resources to actually go out into the field and talk with folks. I'm wondering if you have any recommendations for folks. Is it still just a matter of getting out there and interviewing people, or do you have any other ideas for teams that just don't have the resources to be out there in the field? Kim: Sure. One thing is just the misconception that when you start using the word 'research,' people automatically start thinking months and millions. That's really not the case. You can do pretty good research for a simple product in just a matter of a few days. You can do research for a really complicated enterprise application in under a month in a lot of cases. So, it's a matter of making sure people understand the scale of effort you're talking about. When we have a really tight contract, our approach is to look around at friends and acquaintances and say, "OK. Can we find just a handful of people who are at least something like the type of user we're trying to recruit and get some of their time?" Because even three or four perspectives different from our own can still help us to see the world in different ways, and the typical user is not like that. Christine: So even if folks can't get their actual user groups-if they're finding people who are similar enough... Kim: Yeah. Yeah, it's not ideal, right, and obviously you'll have less constance in what you're designing, and you really don't want to bet a multimillion-dollar development effort on three casual user interviews with friends of friends. But, even so, if your time frame is compressed and it's the only choice you have, it's better than not doing anything. Christine: Exactly. And this is one thing we're hearing from clients, is that they understand how important user research is, but because they can't actually access their real users, they're just not talking to anyone. Even our philosophy is: If you can talk to someone, if you can watch someone that's similar to your user, that's better than nothing. Kim: Yes, get out of your cubicle and go see some real humans for a while. That'll help. Christine: Now this is a tough question, but we've been getting questions a lot. So for Cooper design projects-obviously there's a wide scale. You're sometimes working on simple products or more complex. With the goal-directed methodology, how long does the typical design project take-from start to finish-for you folks? Clearly... Kim: It depends on the parameters. We certainly do some quick and dirty projects where we're just delivering as much design goodness as we can in a two-week time frame. We do other projects where we're dealing with incredibly complicated systems where we may be working closely with a client for a year or more-especially if we're going all the way to the point where we've really spec'd every behavior in the system and we're helping them make detailed development trade-offs and so on. That can take a long time. But if you have your developers working on Version 1.1 while your design team is working on Version 1.5, then the design process needn't slow down the development, which is something people are often worried about. You can uncouple the two for at least a period of time. Christine: OK. And we were talking a little bit earlier about the upfront user research. If people only have time to be talking to three or four users-even if they do have a lot of time-one thing we get a lot of questions about in the upfront research is when people start going out and interviewing users about what their needs are for a product, do you have any specific tips for conducting the most effective interviews? Are there certain things that you're just always looking for when you go out to the field to talk to folks and talk to users? Kim: Yeah. Interviewing is kind of a class all its own. I think some of the mistakes people tend to make are directly asking users what they want. In essence, they're abdicating design authority to the users and saying, "What do you want? We'll do anything." You can't really take it literally. You really have to combine interview and observations to get the best informations. See how people behave. Ask questions about how they think. Ask them what a good experience is and what a bad experience is. That's a good way to uncover goals. Watch them perform some typical activities, and you'll see that what they say and what they do tend to differ, and you'll see why you have to really combine the two. But ask them for specific stories rather than generalizations. Self -reporting error is always a big issue-and, of course, avoid leading questions. That's a huge mistake that even very experienced interviewers tend to make. Like if you ask someone, "Do you want Feature X?" Well, maybe they'll say yes, but it's priority number 37 in their list when we'll care about priorities one through six. Christine: Well, it's interesting that you're touching upon--a lot of development teams will start talking with users and ask them to design what their ideal interface would be or their ideal product. Our audience at UIE, they recently had the opportunity to read one of your articles-one of the articles that was originally published on Cooper's site that we just republished on uie.com-about some of the ways-ten ways to kill good design. One of the things you touched upon wasn't necessarily having users do the designing, but you did touch upon-one of the biggest problems can be if the programmers within the organization are doing the design, that that can also be a problem. Kim: Right. For people to believe that design itself is an effective tool, they need to see it done well. It's like any other discipline. You're not necessarily going to believe that western medicine is useful unless you actually have a competent doctor. You're not going to believe that some-most anything that's good for you is good unless you see it done well. So having dedicated designers who actually know what they're doing makes a big difference. Now, sure, there are a lot of developers out there who just don't have access to design teams, and what those folks need to do is try to put aside their developer hats for a little while and not think about how they're going to implement it, but instead think about the users and try to separate the two activities and put up a little mental firewall so that they can at least try to focus on the human parts of the activity. Christine: Now, with the projects you're working on, your team at Cooper, what types of team members do you have on particular projects? Obviously you have an interaction designer on board for all of your design projects? Kim: Right. Christine: Who else do you recommend being members of the design team? Kim: Our typical design team consists of four people most of the time. One is a full-time interaction designer who works on that project and only that project. Another is also full-time on the project. We call this role a "design communicator." This is something that we invented-gosh, I don't know, maybe 11 or 12 years ago now. At first we thought, "Hey, let's hire technical writers to document what the interaction designers are coming up with." Well, you'll find 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?" And we found that, by hiring the right people, they were naturally inclined to help us refine the design and clarify it and be very rigorous in making sure it was fully articulated and that we had considered everything. So this role has really become a design partner. 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." Christine: Right. So initially it wasn't... Kim: It helps people think it through. Christine: When you were starting with these roles 11 years ago, were you initially conceiving that the design communicator would not be as actively involved as the designer? Kim: I think that was our initial belief, but we hired some sharp people and that notion quickly went out the window as the interaction designers realized, "Oh, I'm smarter with this person in the room," and pretty soon it became a really indispensable part of our practice. Of course, we also generally have a visual designer on the vast majority of our projects because we find that the visual and emotional aspects of the product-they're not really separable from the interaction in a good design, but you need someone who's extremely skilled in that area and paying close attention to it to make sure that it doesn't suffer in favor of the practicalities of interaction designs. Christine: Right. Kim: And then every one of our projects also has an engagement lead- someone like myself-who is trying to balance all the different disciplines and deal with project management and stuff like that as well. And we may have an industrial designer as well if there is hardware. Christine: OK. I met you, I believe now, back in 2001. Kim: That sounds about right. Christine: How long have you been at Cooper? Kim: Coming up on 10 years. Christine: OK. So I'm curious, and this is something I've been asking a lot of designers and folks working in design consulting companies. Now that you've been working at Cooper for close to a decade, have you seen any major changes in the way your work is being done now, a decade later? Has the world of design changed at all? Are you finding any different challenges? Kim: I would say the biggest shift is that 10 years ago, we were explaining what the heck interaction design even was, and we were arguing with people about why they even needed to do design. Certainly there are still places where you need to explain that, and make that argument; our job is not done in that respect. But, in many cases, we don't have to explain what we do any more. It's more a matter of explaining how to do it really well. You know, 10 years ago, if you wanted to be an interaction designer, there really weren't a whole lot of places to work. In fact, there weren't a whole lot of people who knew what it meant. Now, you can go on some very broadly targeted job boards, like Monster, and see dozens of listings for interaction designers. So a lot more companies are realizing that design is something they need to have as a core competence; that it's not something they want to outsource, because it's really central to the definition of, and the perception of, their products. So design is much more accepted than it used to be. I think that as designers, we have a lot more respect, and a lot more opportunities, than we did 10 years ago. Christine: So, theoretically, that's making your life easier? [laughs] Or busier now? Kim: I wouldn't say easier. I think it just introduces new challenges. For example, OK, you have more opportunities to do design, and you're being brought in earlier. Well, OK, there are still challenges with making sure that an organization can actually metabolize design. Just because you have a great design, and it's detailed in a gorgeous spec, doesn't mean that the organization is going to succeed in building it. So we, as designers, need to make sure that we are preparing our clients -- and I think that internal designers have clients too, the organization -- that we're preparing our clients to really make the best use of that design. I believe that solving the design problem is, at most, half of a designer's work. The other half is making sure that the organization understands it, accepts it, wants to build it, and can succeed at building it. Christine: OK, good. OK, I couldn't have an entire conversation with you without touching upon the topic of usability testing. Kim: [laughs] OK. Christine: Because I think we've had this conversation before. [laughs] I think there's a misconception -- and we're still hearing this -- there's a misconception that the folks at Cooper, yourself included, don't necessarily buy into the value of usability testing. And I do believe that it's a misconception on folks' parts, but I wanted to give you a chance to talk a little bit about it. Do you think usability testing fits into the design process, and if so, where? Kim: I absolutely believe that it does. And Cooper, as an organization, believes the same. I think the misconception comes from, 10 years ago, Alan Cooper was saying, "No, don't waste your time with usability testing, do design." And his speaking style, and his writing style, are very black and white, and he says that sort of thing to make a point. And his point was that people were using usability testing to try to substitute for design, and the two are not the same. They don't serve the same purpose. I often use the analogy that usability testing is to design what QA is to development. It's a valuable tool, but you really can't substitute one for the other. You can use usability testing to identify the fact that you have a problem. It's a very powerful persuasive tool in that respect. You can also, as a designer, use usability testing to tell you, "Oh, I missed something there." But it doesn't necessarily substitute for up-front developing an understanding of how people think, and doing good design. It'll take you a whole lot longer to get to a good solution, just iterating through a ton of different usability tests, than it will doing good research, doing good design. Then, you won't find nearly as much stuff wrong when you do a usability test. Christine: Exactly. So, in terms of usability testing, it clearly can't really make up for an awful design, or a bad design, but it does have its place. Kim: Yeah. Christine: According to Cooper. [laughs] OK. Kim: Absolutely, and if you need to persuade people that you even need to do design, then I think in that event, usability testing does have an up-front role, because nothing is more persuasive than -- well, OK, other than a horrible bottom line -- nothing is more persuasive than sitting people down in front of a product and having everyone watch them struggle. But in general, we advocate doing your research, doing your design, getting it to the point where it's concrete enough that you're not asking users to imagine and fill in gaps in the design, and then running people through some typical tasks to help refine what you're doing... Christine: Right. Kim: ...and identify problems. Christine: OK, good. I think that will clarify some things [laughs] for our audience. Kim: Well, thanks for clearing the air. Christine: [laughs] I know I've talked to you about this quite a bit, so I knew what you would say, but... Kim: [laughs] Yes. Christine: So Kim, you're speaking at UI12 in November. This is, I think, the sixth or seventh time you've presented, but you're presenting... Kim: Is that all? I think it's been more than that, even. Christine: Has it really? [laughs] Six or seven times while I've been here, I think. You're always one of our most popular presenters. But what I'm really excited about is, you're presenting a new seminar for us this year, "The Essentials of Interaction Design." Can you just quickly -- in one minute or so [laughs] -- touch upon some of the topics you're planning on covering for our folks? Kim: Sure. I think the UIE audience, in particular, has heard me talk a lot about personas, and about research, and this class really is not about that. It's about "what do you do once you have those things?" It's partly about skill building, how do you develop your essential design skills, like visualization -- how do you get to the point where you can confidently make marks on the whiteboard, and have it mean something. And the other piece of it is, "How do you use scenarios, patterns, and principles combined to visualize and iterate solutions?" So it's really about the design creation part of the design process. And not so much about the "getting ready to design, by understanding the problem and articulating it" part of the process. It's really that middle part, where you're ideating and refining. Christine: Right, right. Well, good. I'm excited to be seeing you in November. I'm looking forward to it. For those of you interested in learning more about Cooper, and the work that Kim and the folks at Cooper are doing, I highly suggest you check out their website at www.cooper.com; and if anything you found was enlightening or interesting in this conversation I've had with Kim, I highly suggest you check out our conference site. Our UI12 conference site is www.uiconf.com. Kim, thanks very much for talking with me today. It was fun. Kim: Thanks as always for having me, and I'm looking forward to November. Christine: Definitely. Thank you. Kim: Thanks. Take care. Christine: Bye. Kim: Bye. [music] Brian: We hope you've enjoyed this SpoolCast. You can comment on this and other episodes, as well as find more UIE podcasts, at uie.com/audio. Don't forget that Kim Goodwin and Christine Perfetti will both be presenting at our user interface conference this November in Cambridge, Massachusetts. Now in our 12th year, the UIE conference allows you four straight days of learning with some of the world's top designers, information architects, and usability professionals. We invite you to find out more at uie.com/events. That's all for this week. Thanks for listening. Goodbye. [music]