The Cooper Journal: Entries about Personas

Putting personas under the microscope

by Suzy Thompson on July 7, 2009 | Comments (3)

We recently came across a research study conducted by Frank Long at the National College of Art and Design that investigated the value of personas as a design tool. In his research paper, titled "Real or Imaginary: The effectiveness of using personas in product design," Long concludes:

The results showed that, through using personas, designs with superior usability characteristics were produced. They also indicate that using personas provides a significant advantage during the research and conceptualization stages of the design process.

I’m impressed by Long’s efforts to gather evidence to support the claims of persona fans like myself, and am not surprised by the positive outcomes attributed to the use of personas. But in the debate over personas’ usefulness, I’m not quite ready to spike the ball and call it game over just yet.

As we all know, skeptics of personas abound. I won’t be dedicating my life to converting the non-believers, but I hate to see designers dismiss a useful tool simply because its’ worth has not been adequately demonstrated to them. Frank Long’s research is a great start, but I suspect that more work is needed to deliver compelling evidence that will persuade the detractors.

Personas used to explain the pain of ERP systems on Forbes.com

by The Editors on March 16, 2009 | Comments (0)

Enterprise resource planning systems must, by their very nature, serve the needs of a wide variety of people, and the implementation of these systems can result in the needs of one person being sacrificed in order to meet the needs of another. In an article on Forbes.com, Dan Woods does a nice job of laying out the pitfalls and frustrations attending ERP and other monolithic business software.

We particularly like the article because he mentions Alan and credits him for formalizing the use of personas, but it's also a sophisticated look at how system design is begging for effective tools to understand the network of human needs that must be balanced in order to create effective solutions:

...[S]ome users get more value from software applications than others. This is because software is written from a certain user perspective. In many cases, the problems and challenges faced in making software work can be explained by the tension created when the design of software is dominated by one perspective over another. In CRM systems, for example, the sales reps who must do the work of entering data about contacts and meetings often must be bludgeoned or bribed to do so. They get little benefit from such tracking, as opposed to the VP of sales, for whom the data is a vital way to understand what is happening.

Check it out "One Software Doesn't Fit All" on Forbes.com.

What do you think? Join the conversation in Comments

Joe six pack is not a useful archetype

by Lane Halley on October 24, 2008 | Comments (1)

A good persona (or user archetype) is based on research and is specific, memorable and includes actionable information. Often, I’ve seen people give them descriptive names that leverage often-heard phrases, like “Nora the newbie” or “Joe Helpdesk.”

The term “Joe Six Pack” has frequently been used in the 2008 presidential campaign. This is a good example of how using “soundbite” names for your persona work against your need for a specific design target that keeps everyone on the team focused on the same idea.

In NPR’s Morning Edition program “York Voters Untangle Rhetoric On Race” Renee Montagne, Steve Inskeep, Michele Norris asked 15 voters from York Pennsylvania what they thought of when they heard the term “Joe Six Pack.” The got a variety of responses:

Human motivation as a way to understand user goals

by Stefan Klocek on October 20, 2008 | Comments (3)

At Cooper we talk a lot about goal-directed design. Usually the term "goal" is used without an explicit distinction between goals and a motivations. The distinction is an important one which can influence design.

Users enjoy the satisfaction of achieving their goals. User goals help us focus our design on solving meaningful problems for the user. If we design with the user's goals in mind, in the best case we will help them achieve their goals, at worst we stand out of the way.

Goals are defined as the "state of affairs that a plan is intended to achieve". Goals are what a person wants to do, achieve, or become. They are boundaries to states that people strive toward, and once they reach either terminate their efforts, or shift into a maintenance of the achieved status. Feeling smart, getting the best deal, and living the good life are all examples of goals. They represent a desired end-state of a set of particular actions.

Motivations are the drivers behind setting and pursuing goals. Motivation is why someone wants to do something. Motivation is what arouses and sustains action toward a desired goal. It gives purpose and direction to behavior.

In researching this, I was disappointed to find that there is little consensus on what are the core motivational needs. Some theorists claim motivation comes from stimulus-response, others from affect, others describe motivation in terms of social or cognitive drive. A survey of the major motivational theories reveals a few commonalities. Needs, desires and wants are the sources of motivation. Motivation directs behavior toward increasing, decreasing, or maintaining a specific state. Dr. William Huitt's list of motivational needs provides an overview of all of the major theories. I have distilled this list into the essentials.

Faces in the crowd: Early persona history

by Lane Halley on August 6, 2008 | Comments (0)

A few days ago, Liz Bacon and Steve Calde presented their talk "Death to Personas! Long Live Personas!" to the Catalyze community. During the webinar, which addressed some common misconceptions about personas, Liz shared some early persona history from her time at Cooper. This got me thinking about how personas have evolved at Cooper during the time I've been here.

In his article "The Origin of Personas" Alan Cooper reviews his early use of personas back in 1995. By the time I joined Cooper in 1997, personas were in regular use as a design tool, but the way we presented them to our clients continued to evolve.

I recently had an e-mail conversation with Nate Myers, a former Cooperista, about his memory of the Sony Trans Com's P@ssport project. Here are Nate's recollections.

To my knowledge, Sony P@ssport was the first project to use pictures. There were no conversations about using photos; I just made the decision to include them in my draft document for several reasons:

During the first meetings I attended as a new employee, I noticed communication issues between Cooper and its clients, many of which revolved around the 'elastic user' problem. By using pictures of real people, who in some cases were dramatically different from the tech-savvy users imagined by clients, I hoped to curtail (or even eliminate) the frequent raucous arguments about 'the user.' We could all look at the same photo and quickly build up a set of shared assumptions that fit the face looking back at us.

In projects prior to Cooper, I noticed that sample users were often given whimsical names, usually based on Looney Tunes, Star Wars or Star Trek characters. However, I saw real business value in identifying user goals by personas, so why undermine that value with a silly name? This didn't mean some of our names couldn't have subtle humor: Clevis McCloud and Mel "Hoppy" Hopper had a touch of fun built in. But even this humor was by design; both names sounded earthy and pragmatic, helping us keep far away from conceptual power users who could easily negotiate software complexity. Since Cooper was already avoiding the silly name trap, matching a realistic photo with a realistic name would only help to enhance the business value of personas.

In our initial conversations with Sony, we had a lot of discussions about idioms and user expectations. Looking at the process of airline travel as a single experience, I asked myself what would happen if users came to P@ssport after interacting with several different procedures and systems during their total airport and flight time. Wanting to help communicate the idea that simpler is better, I included visual flight maps as part of our design document, showing travelers with direct and connecting flights. On paper it seemed just as important to show the passengers as it did the routes.

From previous freelance work, I had two Photodisc CDs filled with pictures of travel, leisure and industry. The pictures on the CDs lent themselves very well to our needs for Sony P@ssport. The most challenging picture was for a child traveling alone; we had specified a pre-teen boy, but the only picture close to it was of a 3-5 year-old girl with a pony tail. As I Photoshopped the pony tail out of the picture I thought to myself, "Wouldn't it be interesting if this picture ended up in a book someday?"

The project team liked the draft with the photos included, so we went with it. I'm glad. It was a good idea.

If you'd like to read more about the Sony Trans Com P@ssport project, there's a case study in Alan Cooper's Book "The Inmates are Running the Asylum."

What do you think? Join the conversation in Comments

Full disclosure: This information has been processed

by Stefan Klocek on August 5, 2008 | Comments (0)

When we create a persona or a model organization, we're deliberately creating an archetype — a person or company that does not map to any one "real" person or company out there in the world. In creating personas, we need to be up-front with ourselves and our clients about the choices and assumptions we made along the way. We also need to be clear about what questions we asked and what we didn't. When we don't have the data, we need to acknowledge this and rectify it if necessary.

This point may seem like a methodological nuance, but it relates to ethical considerations that in other realms, as I recently discovered.

My design partner Chris Noessel and I just completed three weeks of research travel around the world. Neither of us had been to many of the countries, and we both photographed our adventures obsessively. One morning, he asked me to compare a photo he took to one that I took: Why did they look so different? We were using almost identical cameras and taking photos often of the same views.

Chris's photo.

My photo.

Why does mine look different? Because I adjust the photographs post-capture, slightly adjusting the contrast, lightness, and so on. For me, the unprocessed photos rarely convey my experience of the event or location, and the post-processing is intended to re-create my memory of the experience. I take photographs to share that experience, not to share the exact pixels the camera captured.

Chris admitted that it made my photos "look better," but that I "took liberties" to adjust, and once I started, where would I stop? How much change was too much change? How different could it be from his untouched version and still be the Great Wall of China?

Of course, this is part of a much larger conversation. Photographs appear to be very faithful representations of reality, so one may argue that viewers of photography bring a different set of expectations to them than they do to other visual art. Viewers expect photos to be more "real," more true to life, and therefore post-facto monkeying could be seen as deceiving. On the other hand, who is to say what "real" is, really?

Essayist and photo critic Susan Sontag addresses this argument in the introduction to her book, On Photography.

In deciding how a picture should look, in preferring one exposure to another, photographers are always imposing standards on their subjects. Although there is a sense in which the camera does indeed capture reality, not just interpret it, photographs are as much an interpretation of the world as paintings and drawings are.

Even before taking the shot every photographer has made choices which will affect the captured image — camera and lens, film v. digital, SLR v. point-and-point shoot — and each has an effect on the contrast, color, and depth of field, aspect ratio, and so on. We can continue to split hairs, too; for instance, we accept that the journalist which uses a telephoto lens is "telling the truth" even though it grossly manipulates scale between foreground and background. With so much noise in the system, it seems arbitrary to assign "reality" to the raw output of the camera, doesn't it?

The National Press Photographers Association defines a couple of broad categories in the altering of photographs.

There are technical changes that deal only with the aspects of photography that make the photo more readable, such as a little dodging and burning, global color correction and contrast control. These are all part of the grammar of photography, just as there is a grammar associated with words (sentence structure, capital letters, paragraphs) that make it possible to read a story, so there is a grammar of photography that allows us to read a photograph. These changes (like their darkroom counterparts) are neither ethical nor unethical — they are merely technical ... [However], once the shutter has been tripped and the moment has been captured on film, in the context of news, we no longer have the right to change the content of the photo in any way. Any change to a news photo — any violation of that moment — is a lie." [The emphasis is mine].

The NPPA distinguishes between the technical aspects of making photos "more readable" and "changing the content," and I think that this is an interesting analog to the world of creating design targets (i.e., personas, organizations, environments). In our process, you could look at the transition from research to personas is the process of making the research "readable."

Of course, creating personas from research is a lot different than manipulating contrast and lightness in a photo editing app, but the principles are the same: Altering the content is a lie; each archetype that we create should faithfully reflect the gathered information, and each should bring out the priorities, needs and experience imperatives that affect the design. You can monkey with research just like you monkey with photos. When done well, slight adjustments to the color and contrast of the research more effectively reveals the truth. When done badly, they can lie and deceive.

What do you think? Join the conversation in Comments

Does your persona eat twinkies?

by Steve Calde on July 18, 2008 | Comments (2)

I recently stumbled across an article about personas written by Andrea Wiggins late last year in Boxes and Arrows. Wiggins does a nice job talking about how personas can help the design and development process, and some approaches for creating a good persona set. But what really gave me pause was the title: “Building a Data-Backed Persona.” Data-backed? Wait a minute…is there any other kind?

Taking Personas Too Far

by Kim Goodwin on December 23, 2006 | Comments (0)

I don't have to tell you that at Cooper, we love personas—how could we not?—and we're glad to see continued excitement about them. That said, although personas are essential design tools, we think some people may be losing sight of the fact that they're just tools, and tools with a specific purpose, at that. Lately, we've been seeing a lot of gold-plated hammers—unnecessarily elaborate communication about personas—and some fundamental misunderstandings about the relationships among research, personas, and scenarios.

Ignore that designer behind the persona

by Chris Noessel on December 22, 2006 | Comments (1)

One piece of advice I have received in my first year here at Cooper is to avoid referring to personas as creations. Of course they are, and everyone knows it, but they work better if we refer to them as if they were real people in the world. For example, the conversation got off track a bit in one client presentation when I said, "We gave Tracy two kids, with one heading off to college…" The discussion went from being about the personas and the design problem to being about why we gave Tracy two kids, and what tweaks might be made to better fit the persona to the client's expectations. Had I instead said something like "Tracy has two children, the older of whom is about to head to college," the conversation likely would have remained on track. Why is that the case?

Using Personas to Create User Documentation

by Steve Calde on December 2, 2004 | Comments (0)

Personas and other user-modeling techniques are often solely discussed as tools for product definition and design, but they are useful tools in other arenas, as well. Technical writers responsible for creating user documentation can benefit greatly from a well-defined persona set, too.

Using personas to guide your user-documentation creation-process helps you:

Determine the primary and secondary audiences for your documents
Prioritize technical writing tasks by giving you a tool for identifying which aspects of the product are most important to your readers
Write documentation in a way that helps your users achieve their goals, instead of simply cataloguing all of the product's features.

The Origin of Personas

by Alan Cooper on August 1, 2003 | Comments (1)

The Inmates Are Running the Asylum, published in 1998, introduced the use of personas as a practical interaction design tool. Based on the single-chapter discussion in that book, personas rapidly gained popularity in the software industry due to their unusual power and effectiveness. Had personas been developed in the laboratory, the full story of how they came to be would have been published long ago, but since their use developed over many years in both my practice as a software inventor and architectural consultant and the consulting work of Cooper designers, that is not the case. Since Inmates was published, many people have asked for the history of Cooper personas, and here it is.

In their book, Fire in the Valley, authors Paul Freiberger and Mike Swaine, credit me with writing the “first serious business software for microcomputers” as far back as 1975. Like so much software of the time, it was terribly hard to use, and its real power was in demonstrating that making software easy to use was harder than everyone thought. Despite my commitment to making software more user-friendly, it wasn’t until 1983 and about 15 major business and personal applications later that I began to develop a more effective approach.

Getting from Research to Personas: Harnessing the Power of Data

by Kim Goodwin on November 1, 2002 | Comments (0)

The usefulness of personas in defining and designing interactive products has become more widely accepted in the last few years, but a lack of published information has, unfortunately, left room for a lot of misconceptions about how personas are created, and about what information actually comprises a persona. Although space does not permit a full treatment of persona creation in this article, I hope to highlight a few essential points.

Reconciling Market Segments and Personas

by Elaine Brechin on March 1, 2002 | Comments (3)

Market segmentation and personas are two different techniques that are often perceived as conflicting methods, but they are actually complementary tools that organizations can use to design and sell successful products.

The value of market segmentation

The marketing profession has taken much of the guesswork out of determining what motivates people to buy. One of the most powerful tools for doing so is market segmentation, which groups people by their distinct needs to determine what types of consumers will be most receptive to a particular product or marketing message. These groups form a consumer model.

Perfecting Your Personas

by Kim Goodwin on August 1, 2001 | Comments (2)

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype. In most cases, personas are synthesized from a series of ethnographic interviews with real people, then captured in 1-2 page descriptions that include behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to bring the persona to life. For each product, or sometimes for each set of tools within a product, there is a small set of personas, one of whom is the primary focus for the design.