Abstract

‘Personas’ is an interaction design technique with considerable potential for software product development. In three years of use, we and our colleagues have extended Alan Cooper’s technique to make Personas a powerful complement to other usability methods. After describing and illustrating our approach, we outline the psychological theory that explains why Personas are more engaging than design based primarily on scenarios. As Cooper and others have observed, Personas can engage team members very effectively. They also provide a conduit for conveying a broad range of qualitative and quantitative data, and focus attention on aspects of design and use that other methods do not.

Keywords

Personas, user archetypes, user profiles, user research, design method, scenarios, user-centered design

Industry/category

Computer Software, Hardware, & Technology

Project statement

We have used Personas on projects that range from small to large. This paper will discuss two such projects, one small and one large. The smaller project involved the first version a new web browser, MSN Explorer. The larger, our most recent Personas effort, was in support of the Microsoft Windows product development team. The goal of each effort was to help a team identify and understand its target audience as well as aid in design and development decisions for a specific product release.  

Project participants

The MSN Explorer product development team consisted of several hundred members. The Windows product development team changed greatly over time, starting with several hundred members and growing to several thousand at the peak of the effort. Each team comprised programmers, quality assurance testers, program managers, designers, technical writers, product planners, user researchers, and marketing professionals, among others.

The MSN Explorer Persona team included one full-time usability engineer and the part-time efforts of a product designer and two additional usability engineers. The Windows Persona creation team consisted of 22 people: several technical writers, several usability engineers, four product planners, and two market researchers. After the Windows Personas were created, the ensuing Persona campaign involved the part-time efforts of several usability engineers, ethnographers, graphic designers, and product planners.

Project dates and duration

The MSN Explorer Persona effort started in January of 2000 and lasted about 10 months. The actual creation of the Personas took about 2 months. Our Windows Persona effort started around March of 2001 and is ongoing at the time of writing this paper (roughly 2 years), though the initial creation and validation of the Windows Personas took about 3 months.

Process

An Introduction to Personas

The use of Personas, fictional people, in product design is widely heralded: in Alan Cooper’s book The Inmates are Running the Asylum [8], in tutorials by Kim Goodwin of Cooper Design [11], and in workshops [23, 24], newsletters [5, 14, 20], on-line resources [10, 15] and research papers [4, 12, 19].

The use of abstract representations of users originated in marketing [e.g., 18], but Cooper’s use of Personas, their goals, and activity scenarios is focused on design. He notes that designers often have a vague or contradictory sense of their intended users and may base scenarios on people similar to themselves. His ‘goal-directed design’ provides focus through the creation of fictional Personas whose goals form the basis for scenario creation. Cooper’s early Personas were rough sketches, but over time his method evolved to include interviews or ethnography to create more detailed characters [16].

Prior to Cooper, others promoted the use of abstract representations of users to guide design: user profiles and scenarios derived from contextual inquiry [13, 25] and user classes fleshed out into ‘user archetypes’ [17]. These representations were also used as a basis for scenario construction.

Cooper’s approach can be effective, but our use of Personas diverges in several ways. He emphasizes an “initial investigation phase” and downplays ongoing data collection and usability engineering: “Seems like sandpaper… Very expensive and time-consuming, it wasn’t solving the fundamental problem.” [8] Statements such as “We always design before putting up buildings” and claims that designers have an innate ability to make intuitive leaps that no methodology can replace [11] understate the value of user involvement.

Personas used alone can aid design, but they can be more powerful if used to complement, not replace, a full range of quantitative and qualitative methods. They can amplify the effectiveness of other methods.

Personas might help a designer focus. However, their greatest value is in providing a shared basis for communication. Cooper emphasizes communicating the design and its rationale among designers and their clients: “It’s easy to explain and justify design decisions when they’re based on Persona goals...” [16]. We have extended this, using Personas to communicate a broader range of information to more people: to designers, developers, testers, writers, managers, marketers, and others. Information from market research, ethnographic studies, instrumented prototypes, usability tests, or any other relevant source can be conveyed rapidly to all project participants.

Our experience with Personas

We have actively used Personas, and refined our techniques for using them, for over three years. When the MSN Explorer effort began, we did not set out to create Personas. In fact, we were only vaguely familiar with the concept. Our goal was to help a development team understand and focus on a set of target users. We read Cooper’s 1999 book and looked around the industry and our company to see how other teams had defined their audiences and communicated that information to their broader team. Many product teams within our company had done significant work with market segmentation, user role definition, user profiling, and fictional character definitions created for use in scenario-based design. One specific technique, under the name ‘user archetypes’, started around 1995 with a single product team and focused primarily on product planning, marketing, and product messaging [17]. Their approach resembled Geoffrey Moore’s “targeting customer characterizations” [18]. Over time, other product teams adopted their method, and adapted it to better suit product development. Although much of the adoption and adaptation of Persona-like methods by various teams happened independently, common issues arose and similar solutions were developed. From others around the company who had been directly involved with creating these user abstractions or who were expected to use them in product definition and design, we found that the early Persona-like efforts suffered from four major problems:

1) The characters were not believable; either they were obviously designed by committee (not based on data) or the relationship to data was not clear.

2) The characters were not communicated well. Often the main communication method was a resume-like document blown up to poster size and posted around the hallways.

3) There was no real understanding about how to use the characters. In particular, there was typically nothing that spoke to all disciplines or all stages of the development cycle.

4) The projects were often grass-roots efforts with little or no high-level support (such as people resources for creating and promoting Personas, budget for posters or other materials to make the Personas visible, or encouragement from team leaders: “thou shalt use these characters”).

The approach outlined below was developed specifically to address these four problems. It has been refined to address additional issues encountered along the way (how best to create user abstractions? how much can be fictional and what should be based on data? what data is most appropriate? how to combine different types of data? how to validate your creations? can multiple related product teams share a common set of abstractions? how to determine whether the effort was worth it? did the product get better as a result? and so on). Our method and process by necessity combined techniques gleaned from the previous Persona-like efforts with what we could learn from Cooper’s book, which was not written as a “how to” manual.

Our MSN Explorer Personas effort suffered from several problems. First, because this was new to us, we began with little idea of how much work was involved and what would be gained. Thus, obtaining resources and creating reasonable timelines was difficult. We started with no budget and two people, who had plenty of other work to do. We began the Personas effort as the product vision and initial planning were being completed. By the time we finished creating Personas, which took much longer than expected, our team had fully completed the basic design and specification phase of the cycle. We had no time nor resources to do original research, but were fortunate that several field studies and market research pertinent to our product had been completed by others. Finally, the whole idea of using fictional characters to aid design was new to most people on our development team, so there was much resistance to overcome and education required.

By the time we began the Windows Personas effort, our understanding of the method had grown tremendously through our experiences and through sharing experiences with other Persona practitioners [23]. Because of the success of previous Persona efforts and the Persona buzz around the industry, the method had become more familiar and fairly well accepted by the development team. We were given people resources and a decent budget for posters, events, and other promotional exploits. Most important, Personas were being requested by execs and team leaders as well as members of the design and development team. What we had set out to do in our first effort was more likely to be achieved in this larger effort.

Practice details

Creating and using Personas: Our approach

The following is a bulleted sketch of our current process. Where appropriate, we call out differences in the resource-lacking Explorer Personas effort and the resource-intensive Windows Personas effort.

•  We attempt to start an effort using previously executed, large-sample market segmentation studies, much like those discussed by Weinstein [27]. Highest priority segments are fleshed out with user research that includes field studies, focus groups, interviews and further market research. We use metrics around market size, historical revenue, and strategic or competitive placement to determine which segments are enriched into Personas. We try to keep the set of characters down to a manageable number: 3 to 6 Personas, depending on the breadth of product use.

•  Generally, we collect as much existing related market and user research as possible (from internal and external sources) to help inform and “fill out” the Personas. We have yet to start a Persona effort in an area that does not have some existing quantitative and qualitative data. Thus, our own research endeavors typically start after we create our Personas.

•  Although we have not yet created full-on international or disabled Personas, we included international market and accessibility information in our Personas. Several of our partner teams have also created ‘anti-Personas’: Personas intended to identify people that are specifically not being designing for.

•  In our larger Persona effort, involving 22 people, we divided the team so that each Persona (6 in all) had 2 or more dedicated people. At the other extreme, two people created all four MSN Explorer Personas, though a few other people contributed to or reviewed various aspects of the work from time to time. As mentioned, this lighter effort relied solely on existing user research, and as a result generated far less detailed Personas.

•  The Windows Personas effort drew on many research studies. We divvied up the research documents, with each team member becoming well acquainted with only a few studies. We then held “affinity” sessions where we physically cut data points and interesting/relevant facts out of the studies and pinned them to a wall to form groups of related findings across studies. The resulting groups of findings were used in writing narratives that told the story of the data.

•  As we wrote the Personas’ stories, we employed qualitative data and observational anecdotes where possible. A not yet quite achieved goal is to have every statement in our Personas generated from or related to user data and/or observation.

•  In all Persona efforts, we utilize a central “foundation” document for each Persona as a storehouse for information about that Persona (data, key attributes, photos, reference materials, etc.). Figure 1 shows the table of contents for a typical foundation document. Note that the foundation document is not the primary means of communicating information about the Persona to general team members (more on this below). Likewise, the foundation documents do not contain all or even most of the feature scenarios (e.g.., “walk-through” scenarios are located directly in the feature specs). Instead, the foundation document contains goals, fears, and typical activities that motivate and justify scenarios that appear in feature specs, vision documents, story boards, and so forth.

•  Links between Persona characteristics and the supporting data are made explicit and salient in the foundation documents. These documents contain copious footnotes, comments on specific data, and links to research reports that support and explain the Personas’ characteristics. All Persona illustrations and materials point to the foundation documents (which are on an intranet site) to enable team members to access the supporting documentation.

•  Once a basic Persona description is written, we find local people to serve as models and hold one- to two-hour photo shoots to get visual material to help illustrate and communicate each Persona. We have avoided stock photo galleries because they typically offer only one or two shots of a given model and the images are too “slick”.

•  For our Windows Personas effort, after our Personas were created, we set up “sanity check” site visits with users who match the Personas on high level characteristics to see how well they match on low level characteristics. We do this because our creation method utilizes multiple data sources, many of which are not directly comparable or inherently compatible.

•  Once the Personas’ documents and materials are in place, we hold a kick off meeting to introduce the Personas to the team at large.

figure 1. The table of contents for a foundation document

•  Communicating our Personas has been multifaceted, multimodal, on-going, and progressively discloses more and more information about them. Our foundation documents are available to anyone on the team who wishes to review them, but they are not the primary means for delivering information. Instead, we create many variations of posters, flyers, and handouts over the course of the development cycle. For the Windows Personas we even created a few gimmicky (and popular) promotional items (e.g., squeeze toys, beer glasses, mouse pads – sprinkled with Persona images and information). We created web sites that host foundation documents, links to supporting research, related customer data and scenarios, and a host of tools for using the Personas (screening material for recruiting usability test participants, spreadsheet tools, comparison charts, posters and photos, etc.). In an ongoing “Persona fact of the week” email campaign, each Persona gets a real email address used occasionally to send information to the development team. Figure 2 shows two general posters designed to further a team’s understanding of the Personas. One compares important characteristic of four Personas. The other communicates the fact that our Personas are based on real people and tries to provide a sense of the essence of a Persona by providing quotations from real users who are similar to that Persona. Figure 3 shows two posters from a series that provides information specifically about how customers think about security and privacy. The first again provides real quotes from users who fit our various Persona profiles. The second poster shows how a real hacker targeted people who resemble one of our Personas.

·    We instruct our team in Persona use and provide tools to help. Cooper describes Persona use mostly as a discussion tool. “Would Alan use this feature?” This is valuable, but we have generated additional activities and incorporated them into specific development processes. We created spreadsheet tools and document templates for clearer and consistent Persona utilization. As an example of how Personas can become explicitly involved in the design and development process, Figure 4 shows an abstract version of a feature-Persona weighted priority matrix that can help prioritize features for a product development cycle. In the example, the scoring in the feature rows is as follows: -1 (the Persona is confused, annoyed, or in some way harmed by the feature), 0 (the Persona doesn’t care about the feature one way or the other), +1 (the feature provides some value to the Persona), +2 (the Persona loves this feature or the feature does something wonderful for the Persona even if they don’t realize it). The sums are weighted according to the proportion of the market each represents. Once completed, the rows can be sorted according to the weighted sum and criteria can be created to establish what features should be pursued and what features should be reconsidered. Shown below, features 2 and 4 should be made a high priority for the development team; feature 3 should probably be dropped.

figure 2. Two general posters: one comparing characteristic across Personas; the other presenting real quotes from users that fit the profile of one of our Personas

figure 3. Two more targeted posters: one communicating aspects of security and privacy across all of our Personas; the other showing how certain types of hackers can target one of our Personas

(Note: these images are intentionally small and hide detail to preserve proprietary information in them.)

figure 4. A feature by Persona weighted priority matrix

•  We make a strong effort to ensure that all product and feature specification documents contain walk-through scenarios that utilize our Personas. We do the same with vision documents, storyboards, demos, and so forth. Unfortunately for the MSN Explorer effort, we completed our Personas too late in the process to utilize this approach.

•  During the Windows Personas effort, we collected Persona scenarios from across the product team in a spreadsheet that enables us to track and police the use of the Personas (this also enables us to roughly gauge the direction of a product as it is developed – e.g., how many scenarios are written for Toby vs. Abby when we know Abby is a higher priority target).

•  Design teams have made creative visual explorations based on the Personas. More specifically, they created branding and style collages by cutting and pasting images that “feel like” our Personas from a variety of magazines onto poster boards (see Figure 5). They then utilized these boards to do a variety of visual treatments across several areas of our product. In another Persona effort, we took these types of explorations to focus groups to understand in detail what aspects of the designs were appealing and how they worked together to form a holistic style. Although the Personas were not critical to this process, they served as springboard that inspired creation.

•  As a communication mechanism useful to the Persona team itself, we create Persona screeners and recruit participants for usability and market research. We then categorize, analyze, and report our findings by Persona type. For the Windows Personas, we have gone to the extreme of creating a Persona user panel. Through an outside firm, we established a 5000 person panel of users that match our Persona profiles. We poll the panel on a regular basis to better understand reported activities, preferences and opinions, as well reactions to our feature plans, vision and implementations. We have not aged our Personas over time, but we do revise them as new data becomes available. Unlike Cooper, we support a strong, ongoing effort to obtain as much quantitative and qualitative information about users as possible, thereby improving the selection, enrichment, and evolution of sets of Personas.

figure 5. A Persona focused style collage.

•  One of our technical writing groups, a partner to the Windows team, utilized the Windows Personas to plan and write “How to” and reference books for the popular press. In doing so, they expanded the Personas to include notions of learning style, book usage patterns, and so forth to enrich how they authored for specific audiences.

•  Although, this hasn’t happened for the Persona efforts described here, in other efforts the quality assurance test team has used Personas to organize bug bashes and select/refine scenarios for their QA testing.

figure 6. A design exploration based on the above style collage.

•  For the Windows Personas, we undertook a large effort to reconcile two sets of target audiences (one in the form of Personas and one in the form of customer segments) when a team working on a related product was directed to be “better together” with our product.

Results

Benefits of Personas

It is clear to us that Personas can create a strong focus on users and work contexts through the fictionalized settings. Though we have not tried to formally measure the impact of our Personas, the subjective view of the Personas and the surrounding effort by the development team has been favorable. A wide range of team members (from executives to designers and developers) know about and discuss our product in terms of the Personas. We’ve seen Personas go from scattered use (in early Persona projects) to widespread adoption and understanding (in recent product cycles). Our Personas are seen everywhere and used broadly (e.g., feature specs, vision documents, storyboards, demo-ware, design discussions, bug bashes – even used by VP’s arguing for user concerns in product strategy meetings). Not only have our development teams engaged with Personas, but correspondingly they have engaged with our other user-centered activities. Our Persona campaigns generated a momentum that increased general user focus and awareness. With our most recent Persona effort, we’ve had partner teams building related but different products adopt and adapt our Personas in an effort to enhance cross-team collaboration, synergy and communication.

The act of creating Personas has helped us make our assumptions about the target audience more explicit. Once created, the Personas have helped make assumptions and decision-making criteria equally explicit. Why are we building this feature? Why are we building it like this? Without Personas, development teams routinely make decisions about features and implementation without recognizing or communicating their underlying assumptions about who will use the product and how it will be used. The “feature by Persona weighted priority matrix” described in the previous section is a good example of this. Using that tool inevitably results in favored features or seemingly important features being pushed down in the list. When this happens, teams must be very explicit with their reasoning to get a feature back in the plan. We stress to the team that this tool is not “golden,” it is a guide; exceptions can and should be made, when appropriate.

Personas are a medium for communication; a conduit for information about users and work settings derived from ethnographies, market research, usability studies, interviews, observations, and so on. Once a set of Personas is familiar to a team, a new finding can be instantly communicated: “Alan cannot use the search tool on your web page” has an immediacy that “a subset of participants in the usability study had problems with the search tool” doesn’t, especially for team members who now, for all intents and purposes, see Alan (a persona) as a real person. We have found this to be extremely powerful for communicating results and furthering our teammates’ understanding of the Personas.

Finally, Personas focus attention on a specific target audience. The method helps establish who is and consequently who is not being designed for. Personas explicitly do not cover every conceivable user. They also help focus sequentially on different kinds of users. For example, a quality assurance engineer can one day test a product focusing on Alan scenarios, another day focusing on Laura scenarios. As stated in the previous section, this works for testers and other product team members, in “bug bashes” for example. An experienced tester reported feeling that he was identifying “the right kind” of problems in drawing on knowledge of a Persona in guiding his test scripts and activities. Compare this to an observation from a study of interface development:

Some people realized that tests conducted by Quality Control to ensure that the product matches specification were not sufficient. One manager noted, ‘I would say that testing should be done by a group outside Development. ‘Cause Development knows how the code works, and even though you don’t want it to, your subconscious makes you test the way you know it works… See, those people in the Quality Control group have nothing to do with customers. They’re not users.’

In fact, two members of Field Support were reported to have found more bugs than the Quality Control group in the latest release, and they had accomplished this by working with the product as they imagined that users would. Testing by Field Support was an innovative experiment, however, and not part of the accepted development process.

 ‘The Quality Control group has a lot of systematic testing, and you need some of that, but at the same time, you need somebody who is essentially a customer. It is as if you had a customer in house who uses it the way a customer would every day, and is particularly tough on it and shakes all these things out. That’s what these two guys did, and it was just invaluable.’ [21, p. 64]

The Field Support engineers could “test as a user” because of their extensive experience with customers. That Persona use results in similar positive reports is encouraging.

Risks of Personas

Getting the right Persona or set of Personas is a challenge. Cooper argues that designing for any one external person is better than trying to design vaguely for everyone or specifically for oneself. This may be true, and it does feel as though settling on a small set of Personas provides some insurance, but it also seems clear that Personas should be developed for a particular effort. In making choices it becomes clear that the choices have consequences. For example, they will guide participant selection for future studies and could be used to filter out data from sources not matching one of the Persona profiles.

Related to this is the temptation of Persona reuse. After the investment in developing Personas and acquainting people with them, it may be difficult to avoid over-extending their use when it would be better to disband one cast of characters and recruit another one. It can be good or bad when our partner teams adopt or adapt our Personas. Different teams and products have different goals, so the Personas are stretched a bit. So far, the stretching has been modest and closely tied to data (because our target customers do indeed overlap), but it is a concern.

In addition, marketing and product development have different needs that require different Persona attributes, and sometime different target audiences. Marketing is generally interested in buyer behavior and customers; product development is interested in end-users. We’ve had some success in collaborating here, but there are rough edges.

Finally, we have seen a certain level of ‘Persona mania’ within our organization and others. Personas can be overused. At worst, they could replace other user-centered methods, ongoing data collection, or product evaluation. Personas are not a panacea. They should augment and enhance – augment existing design processes and enhance user focus. We’ve found that Personas enhance user testing and other evaluation methods, field research, scenario generation, design exploration, and solution brainstorming.

Discussion

Theory of mind: how personas work

At first encounter, Personas may seem too “arty” for a science and engineering based enterprise. It may seem more logical to focus directly on scenarios, which after all describe the actual work processes one aims to support. Cooper offered no explanation for why it is better to develop Personas before scenarios.

For 25 years, psychologists have been exploring our ability to predict another person’s behavior by understanding their mental state. ‘Theory of Mind’ first asked whether primates share this ability [22] and then explored its development in children [1]. Every day of our lives, starting very young, we use partial knowledge to draw inferences, make predictions, and form expectations about the people around us. We are not always right, but we learn from experience. Whenever we say or do something, we anticipate the reactions of other people. Misjudgments stand out in memory, but we usually get it right.

Personas invoke this powerful human capability and bring it to the design process. Well-crafted Personas are generative: Once fully engaged with them, you can almost effortlessly project them into new situations. In contrast, a scenario covers just what it covers.

If team members are told “Market research shows that 20% of our target users have bought cell phones,” it may not help them much. If told “Alan has bought a cell phone” and Alan is a familiar Persona, they can immediately begin extrapolating how this could affect her behavior. They can create scenarios. We do this kind of extrapolation all the time, we are skilled at it – not perfect, but very skilled.

The power of fiction to engage

People routinely engage with fictional characters in novels, movies, and television programs, often fiercely. They shout advice to fictional characters and argue over what they have done off-screen or after the novel ends. Particularly in ongoing television dramas or situation comedies, characters come to resemble normal people to some extent. Perhaps better looking or wittier on average, but moderately complex – stereotypes would become boring over time.

Method acting and focusing on detail

Many actors prepare by observing and talking with people who resemble the fictional character they will portray. As with Personas, the fictional character is based on real data. An actor intuits details of the character’s behavior in new situations. A designer, developer, or tester is supported in doing the same for the people on whom a Persona is based.

Method acting uses a great deal of detail to enable people to generate realistic behavior. Detailed histories are created for people and even objects, detail that is not explicitly referred to but which is drawn on implicitly by the actor.

A fiction based on research can be used to communicate. For example, watching a character succumb slowly to a dementia on ER, one can understand the disease and perhaps even design technology to support sufferers, if the portrayal is based on real observation and data.

Merging personas with other approaches

As noted above, we see Personas complementing other approaches, or used where another approach is impractical.

Scenarios and task analysis

Scenarios are a natural element of Persona-based design and development. In Carroll’s [7] words, a scenario is a story with a setting, agents or actors who have goals or objectives, and a plot or sequence of actions and events. Given that scenarios have “actors” and Personas come with scenarios, the distinction is in which comes first, which takes precedence. Actors or agents in scenario-based design are typically not defined fully enough to promote generative engagement. Consider Carroll’s example:

“An accountant wishes to open a folder on a system desktop in order to access a memo on budgets. However, the folder is covered up by a budget spreadsheet that the accountant wishes to refer to while reading the memo. The spreadsheet is so large that it nearly fills the display. The accountant pauses for several seconds, resizes the spreadsheet, moves it partially out of the display, opens the folder, opens the memo, resizes and repositions the memo and continues working.”

The lifelessness of characters in such scenarios has been critiqued from a writer’s perspective [19] and by scenario-based design researchers who suggest using caricatures, perhaps shocking or extreme ones [6, 9]. Bødker writes in [6] “It gives a better effect to create scenarios that are caricatures… it is much easier… to relate to… Not that they ‘believe’ in the caricatures, indeed they do not, but it is much easier to use one’s common sense judgment when confronted with a number of extremes than when judging based on some kind of ‘middle ground.’” She also recommends constructing both utopian and nightmarish scenarios around a proposed design to stimulate reflection.

Task analysis is generally directed toward formal representations that are particularly difficult to engage with generatively. An exception is [2], which recommends detailed character sketches.

These thoughtful analyses point to weaknesses in scenarios taken alone. Unless based strongly on data, a scenario can be created to promote any feature, any position (utopian or dystopian), and can be difficult to engage with.

Personas need not be extreme or stereotyped characters; the team engages with them over a long enough time to absorb nuances, as we do with real people. This duration of engagement is critical. In a movie, heroes and villains may be stereotyped because of a need to describe them quickly, as with stand-alone scenarios. But in an ongoing television series or a novel, predictable stereotypes become boring, so more complex, realistic characters are more effective.

Contextual design and ethnography

Contextual Design [3], a powerful approach to obtaining and analyzing behavioral data, is a strong candidate for informing Personas. As it evolved over two decades, Contextual Design increasingly stressed communication with team members, ways to share knowledge acquired in the field. Personas are primarily a tool to achieve this and thus a natural partner to Contextual Design [4, 14].

Ethnographic data may help the most in developing realistic Personas when available in sufficient depth. Quantitative data may be necessary in selecting appropriate Personas, but does not replace observation. Again, the parallel to method acting arises.

Why not just use real people? Designing for a real person is better than designing blind, but about everyone has some behaviors one would not want to focus design on. Using a real individual would exclude or complicate the use of data from market research, usability testing, and so on. It could undermine the confidence of team members in the generality of particular behaviors – team members do step back and recognize that a Persona represents a group of people, as when they describe “testing six Alan’s.”

Participatory design and value-sensitive design

Participatory or cooperative design focuses on the eventual users of a system or application. It has the same goal of engaging developers with user behavior and also enlists our ability to anticipate behaviors of familiar people. When designing for a relatively small, accessible group of people, this approach makes the most sense. Product development is more challenging for participatory design. We discuss the relationship of Personas and participatory design in depth in [12].

Early participatory design efforts included a strong focus on sociopolitical and ‘quality of life’ issues. These issues are more significant today as the reach of computing extends [26]. Although the industry and many companies have engaged these issues at a high level, most usability and interaction design techniques avoid addressing these issues.

Persona use brings sociopolitical issues to the surface. Each Persona has a gender, age, race, ethnic, family or cohabitation arrangement, socio-economic background, work and/or home environment. This provides an effective avenue for recognizing and perhaps changing assumptions about users. If one populated a Persona set with middle-aged white males, it would be obvious that this is a mistake.

Cooper writes that “all things being equal, I will use people of different races, genders, nationalities, and colors.” Realism, not “political correctness,” is his stated goal. He stereotypes if he feels it will provide more credence and avoids casting strongly against expectations if he feels it will undermine credibility.

Persona use does require decision-making. It isn’t a science. If not used appropriately, any powerful tool can take one down the wrong path, as in lying with statistics or using non-representative video examples. Personas are one such powerful tool. It is up to all of us together to develop effective ways to use them.

Acknowledgments

We thank Gayna Williams, Shari Schneider, Mark Patterson, Chris Nodder, Holly Jamesen, Tamara Adlin, Larry Parsons, Steve Poltrock, Jeanette Blomberg, and members of the Microsoft Personas and Qual groups.

References

[1]      Astington, J.W., & Jenkins, J.M. (1995). Theory of mind development and social understanding. Cognition and Emotion, 9, 151-65.

[2]      Benyon, D. & Macauley, C. (2002). Scenarios and the HCI-SE design problem. Interacting with computers, 14, 4, 397-405.

[3]      Beyer, H. & Holtzblatt, K. (1998). Contextual design. Morgan Kaufmann.

[4]      Blomquist, Å. & Arvola, M. (2002). Personas in action: Ethnography in an interaction design team. To appear in Proc. NordiCHI 2002.

[5]      Brechin, E. (2002). Reconciling market segments and Personas. http://www.cooper.com/newsletters/2002_02/reconciling_ market_seg ments_and_Personas.htm

[6]      Bødker, S. (2000). Scenarios in user-centred design – Setting the stage for reflection and action. Interacting with computers, 13, 1, 61-75.

[7]      Carroll, J. (2000). Making use: Scenario-based design of human-computer interactions. MIT Press.

[8]      Cooper, A. (1999). The inmates are running the asylum. Macmillan.

[9]      Djajadiningrat, J.P., Gaver, W.W. & Frens, J.W. (2000). Interaction relabelling and extreme characters: Methods for exploring aesthetic interactions. Proc. DIS 2000, 66-71.

[10]   Freydenson, E. (2002). Bringing your Personas to life in real life. http://boxesandarrows.com/archives/002343.php

[11]   Goodwin, K. (2002). Goal-directed methods for great design. CHI 2002 tutorial. http://www.acm.org/sigchi/chi2002/tut-sun.html#9

[12]   Grudin, J. & Pruitt, J. (2002). Personas, participatory design, and product development: An infrastructure for engagement. Proc. PDC 2002, 144-161.

[13]   Hackos, J. & Redish, J. (1998). User and task analysis for interface design. John Wiley and Sons, New York.

[14]   Holtzblatt, K. (2002). Personas and contextual design. http://www.incent.com/community/design_corner/02_0913.html

[15]   Hourihan, M. (2002). Taking the “you” out of user: My experience using Personas. Boxes and arrows. http://boxesandarrows.com/archives/002330.php

[16]   Interview with Kim Goodwin (2002). User Interface 7 East.

http://www.uiconf.com/uie-7/goodwin_interview.htm

[17]   Mikkelson, N. & Lee, W. O. (2000). Incorporating user archetypes into scenario-based design. Proc. UPA 2000.

[18]   Moore, G. A. (1991). Crossing the chasm. Harper Collins Publishers, New York.

[19]   Nielsen, L. (2002). From user to character – an investigation into user-descriptions in scenarios. Proc. DIS 2002.

[20]   Perfetti, C. (2002). Personas: Matching a design to the users' goals. User Interface 7 East.
http://www.uiconf.com/uie-7/goodwin_article.htm

[21]   Poltrock, S.E. and Grudin, J. (1994). Organizational obstacles to interface design and development: Two participant observer studies. ACM Transactions on Computer-Human Interaction, 1, 1, 52-80.

[22]   Premack, D. & Woodruff, G. (1978). Does the chimpanzee have a theory of mind? Behavioral & Brain Sciences, 4, 515-526.

[23]   Pruitt, J.S., Jamesen, H. & Adlin, T. (2001). Personas, user archetypes, and other user representations in software design. UPA 2001 workshop. http://www.upassoc.org/conf2001/reg/program/workshops/w2.html

[24]   Pruitt, J.S., Jamesen, H. & Adlin, T. (2002). Creating and using personas: A practitioners workshop. UPA 2002 workshop.       http://www.usabilityprofessionals.org/conferences/2002/program/workshops/wkshop_Personas.php

[25]   Tahir, M. F. (1997). Who's on the other side of your software: Creating user profiles through contextual inquiry. Proc. UPA ’97.

[26]   Value-sensitive design site: http://www.vsdesign.org/

[27]   Weinstein, Art, (1998). Defining your market: winning strategies for high-tech, industrial, and service firms. New York: Haworth Press.