Página principal

Personas: Practice and Theory John Pruitt

Descargar 73.63 Kb.
Fecha de conversión18.07.2016
Tamaño73.63 Kb.
Personas: Practice and Theory

John Pruitt

Microsoft Corporation

One Microsoft Way
Redmond, WA 98052 USA
+1 425 703 4938

Jonathan Grudin

Microsoft Research

One Microsoft Way
Redmond, WA 98052 USA
+1 425 706 0784



‘Personas’ is an interaction design technique with considerable potential for software product development. In three years of use in product development, we and our colleagues have extended 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.


Persona, design method, scenario, user-centered design


The use of Personas, fictional people, in product design is widely heralded: in Alan Cooper’s book The Inmates are Running the Asylum [9], in tutorials by Kim Goodwin of Cooper Design [12], and in workshops [24], newsletters [6, 15, 21], on-line resources [1, 11, 16] and research papers [5, 13, 20].

The use of abstract user representations originated in marketing [19], but Cooper’s use of Personas, their goals, and activity scenarios is focused on design. He noted 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 Cooper’s method evolved to include interviews or ethnography to create more detailed characters [17].

Others have promoted the use of abstract representations of users to guide design: user profiles and scenarios derived from contextual inquiry [14, 25] and user classes fleshed out into ‘user archetypes’ [18]. Like Cooper, they use these representations 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] “We always design before putting up buildings” and claims that designers have an innate ability to make intuitive leaps that no methodology can replace [13] understate the value of user involvement.

Personas as used by Cooper can be valuable, but they can be more powerful if used to complement, not replace, a full range of quantitative and qualitative usability methods. Personas amplify the effectiveness of other methods.

Personas might be used by one designer to help 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...” [17]. 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 source that relates to target users represented by the Personas can be conveyed rapidly to all project participants

Practice: Our experience with Personas

We have been actively using Personas, and refining techniques for using them, for over three years. However, the use of abstract representations of users has had a longer history at our company. It started under the name ‘user archetypes’ around 1995 with one product team and was focused primarily on product planning, marketing, and product messaging. Their approach was more akin to that of Geoffrey Moore (i.e., “Target Customer Characterizations”) [19] than that of Cooper. Over time, other product teams adopted the method, and jointly, other disciplines adapted it to better suit product development [18]. While much of this adaptation by various teams happened independently, it is interesting to note that common issues arose and similar solutions were developed.

Early Persona-like efforts at our company 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 project was, in many cases, a grass-roots effort with little or no support from above (e.g., people resources for creating and promoting the Personas, a budget for posters, T-shirts, and other materials to keep Personas visible; “thou shalt use these characters” encouragement from team leaders).

Interestingly, these four issues were discussed by Blomquist and Arvola [5] in a recent paper describing a Persona effort that was not considered fully successful. These four issues are not exhaustive; there are myriad issues that arise around how best to create user abstractions, what data is most appropriate, how to combine different types of data, how to validate your creations, whether multiple related product teams can share a common set of abstractions, how one determines whether the effort was worth it (did the product get better as a result?), and so on. The approach we describe here was developed specifically to address the four main issues above; though our method has been refined along the way to address the slew of additional issues we encountered along the way

Creating and using Personas: our approach

The following is an outline of our current process:

• We attempt to start each Persona effort from previously executed, large sample market segmentation studies; much like those discussed by Weinstein [27]. The 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, strategic/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 effort typically comes after we create our Personas.

• Although we have not yet created full-on international or disabled Personas, we have included international market information and accessibility information in our Personas. We have only created one ‘anti-Persona,’ a Persona intended to identify people we are specifically not designing for.

• Our most extensive effort involved 22 people over a period of roughly two months. The Persona creation team included product planners, usability engineers, interaction designers, market researchers, and technical writers. We divided the team so that each Persona (6 Personas in all) had 2 or more dedicated people. At the other extreme were less intensive efforts involving one or two people for much shorter periods of time. These lighter efforts capitalized solely on existing user research and generated considerably less detailed Personas.

• When we have many research documents to consider, we divvy up the research, with each team member becoming well acquainted with a few of the studies. In other cases, everyone becomes familiar with all of the research. We then hold “affinity” sessions where we physically cut data points and interesting/relevant facts out of the studies and pin them to the wall to form groups of related findings across studies. Those groups of findings are used in writing narratives that tell the story of the data.

• As we tell the story, we try to employ qualitative data and observed anecdotes when possible. A not yet quite achieved goal is to have each and every statement in the Persona generated from or related to user data and/or observation.

• 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 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, etc.

• 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 refer to the foundation documents (which are on an intranet site) to enable team members to access the supporting documentation.

Overview – Patrick Blakeman (Small Business Owner)

Get to know Patrick, his business and family.

A Day in the Life

Follow Patrick through a typical day.

Work Activities

Look at Patrick’s job description and role at work.

Household and Leisure Activities

Get information about what Patrick does when he’s not at work.

Goals, Fears, and Aspirations

Understand the concerns Patrick has about his life, career, and business.

Computer Skills, Knowledge, and Abilities

Learn about Patrick’s computer experience.

Market Size and Influence

Understand the impact people like Patrick have on our business.

Demographic Attributes

Read key demographic information about Patrick and his family.

Technology Attributes

Get a sense of what Patrick does with technology.

Technology Attitudes

Review Patrick’s perspective on technology, past and future.


Learn how Patrick keeps in touch with people.

International Considerations

Find out what Patrick is like outside the U.S.


Hear what Patrick has to say.


See source materials for this document.

Figure 1. The table of contents for a foundation document

• Once a basic Persona 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 the Persona. We avoid stock photo galleries because they typically offer only one or two shots of a given model.

After our Personas are 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 typically hold a kick off meeting to introduce the Personas to the team at large.

• Communicating our Personas is multifaceted, multimodal, on-going, and progressively discloses more and more information about the Personas. Although our foundation documents are available to anyone on the team who wishes to review them, they are not the primary means for delivering information. Instead, we create many variations of posters, flyers, handouts and a few gimmicky promotional items (e.g., squeeze toys, beer glasses, mouse pads – all sprinkled with Persona images and information). We create a web site that contains the “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.). We have an ongoing “Persona fact of the week” email campaign. And, each Persona gets a real email address which is used occasionally to send feedback email to individuals on the development team who do good things for their users, the Personas.

Figure 2 shows two 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 attempts to give the reader a sense of the essence of the Persona by providing quotations from real users who are similar to that Persona. Figure 3 shows 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.

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

• We instruct our team in using the Personas and provide tools to help. Cooper describes Persona use mostly as a discussion tool. “Would Dave use this feature?” This is valuable, but we have generated additional activities and incorporated them into specific development processes, and created spreadsheet tools and document templates for clearer and consistent Persona utilization.

Figure 3. Two posters communicating aspects of security and privacy for our Personas

As an example of how Personas become concrete in the design and development process, Figure 4 shows an abstract version of a feature-Persona weighted priority matrix that is used to help determine what features are actually built in the product development cycle. In this 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.

Persona 1

Persona 2

Persona 3





Weighted Sum

Feature 1





Feature 2





Feature 3





Feature 4










Figure 4. A feature by Persona weighted priority matrix

• We take great effort to ensure that all product and feature specification documents contain walk-through scenarios which utilize our Personas. We do the same with vision documents, storyboards, demos, and so forth.

• We collect Persona scenarios from across the product team in a spreadsheet that enables us to track and police the use of the Personas (and this enables us to roughly measure the direction of the 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).

• Our test team uses the Personas to organize bug bashes and select/refine scenarios for QA testing.

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

• Our design team does creative visual explorations based on the Personas. More specifically, they have created branding and style collages by simply cutting and pasting images that feel like Patrick, Toby or Abby from a variety of magazines onto poster boards. They then utilized these boards to do a variety of visual treatments across several areas of our product. We then took those explorations to users in focus groups to understand in detail what aspects of the designs were appealing and how they worked together to form a holistic style. While the Personas were not critical to this process, they did serve as springboard to inspire creation.

• As both a communication mechanism and a specific use of the Personas ourselves, we create Persona screeners and begin recruiting participants for usability and market research. We then categorize, analyze, and report our findings by Persona type. Along this line, one project that has proven invaluable was the development of a Persona user panel. Through an outside firm, we established a 5000 person panel of users that match our Persona profiles which we can poll 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 tried to formally measure the impact of our Personas, but have a few ideas on how to do it. Some informal observations are provided in the next section.

• We retired one set of Personas when two teams merged and needed a joint set of target customers. On another occasion we reconciled two sets of target audiences (one in the form of Personas and one in the form of customer segments) when a partner team was directed to be “better together” with our product.

• We have not aged or advanced our Personas over time. But we continue to revise them as new data becomes available. Unlike Cooper, we feel strongly that Persona use needs to be complemented with a strong, ongoing effort to obtain as much quantitative and qualitative information about users as possible, to improve the selection, enrichment, and evolution of sets of Personas.

• More recently, we have begun to develop a set of abstract, fictional businesses (organization archetypes) to help our planning, marketing and sales teams think about how to target and position products to entire companies. The verdict is still out on the utility of this effort.

Benefits of Personas

It is clear to us that Personas create a strong focus on users and work contexts through the fictionalized setting. Subjectively, our development team has favorably viewed the Personas and the surrounding effort. A wide range of team members (from VPs to designers to developers) know about and discuss our product in terms of the Personas. We’ve seen our 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 in product strategy meetings arguing for user concerns). Not only have we seen our development teams engage Personas, but correspondingly they have engaged in our other user-centered activities. In other words, 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 makes explicit our assumptions about the target audience. Once created, they help to keep the assumptions and decision-making criteria 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 to the bottom of the list. When this happens, our teams must be very explicit with their reasoning to get a feature back in the plan. We stress to our teams that this tool is not golden, it is merely 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: “Patrick 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 intensive purposes, see Patrick as a real person.

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 Sondra scenarios, another day focusing on Ichiro scenarios.

As stated in the previous section, this works for testers and other product team members, for example, in “bug bashes.” 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.’ [22, 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 be used to 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 toward Persona reuse. With an investment in developing Personas and acquainting people with them, it may be difficult to avoid over-extending their use when it is time 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. There can be a temptation to overuse Personas. At worst, they could be used to replace other user-centered methods, ongoing data collection, and product evaluation. Personas are not a panacea. They should augment and enhance – augment existing design processes and enhance user focus.

Theory of Mind: How Personas work

At first encounter, Personas may seem too “arty” for a science and engineering based enterprise, and it may seem more logical to focus directly on scenarios, which describe the actual work processes one aims to support. Cooper offers 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’ began by considering whether primates share this ability [23] and continued with explorations of its development in children [2]. 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 “Sondra has bought a cell phone” and Sondra 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 be 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

We see Personas to be complementary to other approaches, or useful where another approach is impractical.

Scenarios and task analysis

Scenarios are a natural element of Persona-based design and development. In Carroll’s [8] 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 [20], and by scenario-based design researchers who suggest using caricatures, perhaps shockingly extreme caricatures [7, 10].

Bødker writes in [7] “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 [3], which recommends detailed character sketches.

These thoughtful analyses point to weaknesses in scenarios taken alone. Unless based strongly on data, they can be created to promote any feature, any position (utopian or dystopian), and they 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 [4], 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 [5, 15].

Ethnographic data is likely the best source for 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 Sondras.”

Persona use parallels ethnography in a sense. Persona users and ethnographers face the challenge of forming an understanding and then communicating it to others. An anthropologist works with information obtained from a few people, over a long time, to reach an understanding, which is then communicated to others through examples that show the norms and ranges of behavior. A good Persona designer works with information obtained from many people, over a short time, to reach an understanding, which is then communicated to others through examples – the Personas – that show the norms and ranges of behavior.

Participatory design and value-sensitive design

Participatory or cooperative design, focusing on the eventual users of a system or application, has the same goal of engaging team members with the behaviors of users. It also enlists our powerful ability to anticipate behaviors of familiar people. When designing a system 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 [13].

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 [9] writes that “all things being equal, I will use people of different races, genders, nationalities, and colors.” He adds that realism, not “political correctness,” is his goal. He stereotypes if he feels it will provide more credence and avoids casting strongly against expectations if he feels it will undermine credibility.

This illustrates that Persona use does involve 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 and it is up to all of us together to develop effective ways to use them.


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 efforts and Qual Group.


1. Adlin, T., Jamesen, H.M. & Pruitt, J. (2002). Personas: Exploring the real benefits of imaginary people. CHIplace. http://www.chiplace.org/techniques/show-article.jsp?id=1

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

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

4. Beyer, H. & Holtzblatt, K. (1998). Contextual design. Morgan Kaufmann.

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

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

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

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

9. Cooper, A. (1999). The inmates are running the asylum. Macmillan.

10. 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.

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

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

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

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

15. Holtzblatt, K. (2002). Personas and contextual design.


16. Hourihan, M. (2002). Taking the “you” out of user: My

experience using Personas. Boxes and arrows. http://boxesandarrows.com/archives/002330.php

17. Interview with Kim Goodwin (2002). User Interface 7 East.


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

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

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

21. Perfetti, C. (2002). Personas: Matching a design to the users' goals. User Interface 7 East.

22. 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.

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

24. Pruitt, J.S., Jamesen, H. & Adlin, T. (2002). Creating and using Personas. 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.

La base de datos está protegida por derechos de autor ©espanito.com 2016
enviar mensaje