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]