Kim Goodwin is Director of Design at Cooper. She uses and teaches a design methodology known as Goal-Directed Design, which emphasizes identifying goals of users before doing any formal design.
We recently interviewed Kim Goodwin:
UIE: Why personas? How did you and your colleagues happen upon this method?
Kim Goodwin: Alan Cooper, our founder, came up with the persona idea a number of years ago. He was attempting to capture a process that he intuitively used to invent and evaluate software. He would ask himself "Who's really using this, and what do they really want to accomplish?" as a way to focus his thinking about the design. The initial incarnation of a persona wasn't much more than a name, an occupation, and a set of goals. The design staff at Cooper has turned this initial idea into a more detailed, more powerful tool that's based on ethnographic research.
We use personas because they are powerful design, measurement, and communication
tools. We use them in design to help us avoid the elastic user problem--where "the
user" is a total novice one minute and a technophile the next--as well
as self-referential design, because designers are seldom representative of
a product's target audience. Personas also help cut through assumptions that
certain tasks are necessary; if a task doesn't directly help accomplish a goal,
we can try to eliminate it. We use personas in scenarios to help us refine
and test the design at the whiteboard, which lets us involve a "user" long
before you'd be able to do a usability test. Personas help us communicate with
each other and with our clients. It's easy to explain and justify design decisions
when they're based on persona goals as well as solid design principles.
The title of Cooper's book and your talk at User Interface 7 East is "The
Inmates Are Running the Asylum". What does this mean?
This is Alan's way of saying that the technology industry is doing things backwards. We always design before putting up buildings or manufacturing physical products, so why should we think it makes sense to build software without a good plan? It's not enough to start with a technical plan, either; architects don't just consider where the plumbing goes-they consider how the space can best meet human needs, then figure out what materials are best suited to the job. Other people might say the process "puts the cart before the horse," but I think Alan's phrase has been much more effective in getting the industry's attention.
You have stated that Cooper doesn't advocate usability testing. Do you see instances where you feel usability testing adds value to the design process?
I think some people have a misperception that Cooper is actively opposed to usability testing. What we're really opposed to is the idea that usability testing can make up for a good design methodology. If you start with a deeply flawed design, usability testing will diagnose many of the problems, but won't necessarily point to a cure. Iteration won't get you to a great design. We feel it's much more effective to do research up front, then follow a methodology that helps translate your findings into a good design.
Once you have a concept that you've decided to test, it's important to be
sure you're testing the right thing. For example, if you put someone in front
of a complex business application and measure its success based on first-time
use, that's a poor test. Immediate ease-of-use is always important, but with
many applications, longer-term efficiency is actually more critical.
You are an accomplished designer and you state that some people (naturally) are more qualified to do design than others. Goal-Directed design works great for those who, like Cooper, are more qualified to do design. For those who are less qualified, is Goal-Directed design still effective? Less-effective? Would you see other design techniques that could in some way compromise for less-qualified designers?
I'd be happy to promote the capabilities of Cooper's design staff, who are certainly well-qualified, but what I mean by "qualified" isn't about where a designer works--it's about the aptitudes and training he or she has.
A methodology is simply a tool that makes it easier to do something. Anyone
can pick it up and use it, but the results will be better when the tool is
in skilled hands. Regardless of the tools you use, design always involves a
moment when the designer has to say "I think it should be like this," and
draw something on the whiteboard that at least comes close to solving the problem.
This is the designer's particular skill: the aptitude--the innate ability--to
turn abstract understandings into concrete solutions, then evaluate those solutions
in an ego-less fashion. That moment of conceptualization is an intuitive leap
I don't think any methodology can replace. The Goal-Directed methodology reduces
the size of the leap and provides tools for evaluating the quality of the result--in
that sense, I think it's probably better for inexperienced designers than some
When you speak at conferences like User Interface 7 East, what do you hope your audience comes away with?
When I do a brief talk, I hope people go away with some conviction that designing before they code is a must, and that designing based on users' goals is the way to do it. When I do a longer workshop, I hope people take home some tools they can use right away. Even if you don't know all the finer points of creating and using a persona, just asking yourself "Who's the user, and what are her goals?" is a powerful way to evaluate a design idea.
What are the biggest design challenges that the web confronts us with today?
The biggest design challenge presented by the web isn't actually a design challenge--it's a business challenge. Because any application designed for the web can be distributed almost for free, companies take that as permission to launch products or services in "web time," without really thinking through the business plan, the design, or a whole host of other crucial factors. There are a lot of reasons for dot-bomb failure, but not understanding customer (user) goals and not taking enough time for quality design are two of the most common.
How did you come to do the work you're currently doing? What precisely do you do in a day at Cooper?
I got into the software world when I joined a tiny health software startup, where I did illustration and animation (which was challenging with only 16 colors available at the time!). Once we hired more than two programmers, it became obvious that someone needed to own the design of the overall product. It fell in my lap. It didn't take long for me to realize that designing interactive software was very different from doing visual design or illustration. I took a variety of usability engineering classes and read every book I could get my hands on.
My typical day at Cooper involves working with our various design teams, scoping
new projects, meeting with clients, refining methodology or training techniques,
reviewing resumes, and being thankful that I work in such a great place.
What's the most effective design team composition you've ever worked with? What makes it so effective (or the others so ineffective)?
Without question, the most effective composition I've seen is our configuration at Cooper. We have two people who form the core of the team, doing the research as well as the design.
One team member is the Interaction Designer, who is primarily responsible for driving the interaction design concept forward and proposing ideas: "It should be like this." The other role, the Design Communicator, was initially conceived as someone who just documented the design but wasn't really a "designer." We found that because the DC was sitting in the design creation meeting and thinking about how to explain the concept, he or she asked questions that helped clarify, refine, and guide how the design was evolving. It became obvious that the DC was a full participant in the design process, and was therefore a designer, too. The dynamic between these two roles is very powerful and makes the team incredibly efficient.
The two skill sets bring some of the advantages of a multidisciplinary team, while the small size minimizes communication overhead and politics about whose idea is the best. If a team does get stuck for more than 15 minutes, they bring in one of our most senior designers (called consulting designers) to help them resolve the disagreement or get past the dead end. Consulting designers typically intervene not by telling the team what to do, but by asking questions that help the team get to a better solution.
In addition, we involve visual design, branding, and industrial design experts
when they're needed during particular projects. Engineers are brought in to
consult when the team needs a feasibility assessment. This provides the necessary
technical input without letting technology drive the design.
What do you do to keep up-to-date and active with being a professional designer? (Read? Present? Research? Sleep? :).
I find that teaching others is a great way to sharpen one's design skills. Solving real design problems is also key. Reading is a must, and not just in the design field--designers must be students of human nature, too.
Describe the closest you've ever come on a project to the ideal process for creating a design from start to finish?
The ideal process is really what we're trying to capture in our methodology. Almost every aspect of the methodology has evolved organically from actual practice.
You have an amazing way with responding to audience questions when you give talks. How is it that you've developed that great skill?
I suppose I'm just very comfortable with the topic, since I answer many of the same questions with new Cooper staff or with clients. I enjoy teaching, too. Also, I think any consultant needs to be good at listening to people, providing thoughtful responses, and not being defensive or needing to have all of the answers.
What's your favorite airplane snack? [Do you always go for the peanuts?]
Lufthansa routinely serves good German chocolate. They win hands-down.
Thanks for your time, Kim. We appreciate it.
Thanks for the opportunity. I have just one last thought for everyone reading the newsletter: whenever the work gets frustrating, just remember that by making technology better to serve human goals, you're making the world a better place.