Persona (user experience)

Within software design, Alan Cooper, a noted pioneer software developer, proposed the concept of a user persona. Beginning in 1983, he started using a prototype of what the persona would become using data from informal interviews with seven to eight users.[4] From 1995, he became engaged with how a specific rather than generalized user would use and interface with the software. The technique was popularized for the online business and technology community in his 1999 book The Inmates are Running the Asylum. In this book, Cooper outlines the general characteristics, uses and best practices for creating personas, recommending that software be designed for single archetypal users.[5]

The concept of understanding customer segments as communities with coherent identity was developed in 1993-4 by Angus Jenkinson[6][7] and internationally adopted by OgilvyOne with clients using the name CustomerPrints as "day-in-the-life archetype descriptions".[8] Creating imaginal or fictional characters to represent these customer segments or communities followed. Jenkinson's approach was to describe an imaginal character in their real interface, behavior and attitudes with the brand, and the idea was initially realized with Michael Jacobs in a series of studies. In 1997 the Ogilvy global knowledge management system, Truffles, described the concept as follows: "Each strong brand has a tribe of people who share affinity with the brand’s values. This universe typically divides into a number of different communities within which there are the same or very similar buying behaviours, and whose personality and characteristics towards the brand (product or service) can be understood in terms of common values, attitudes and assumptions. CustomerPrints are descriptions that capture the living essence of these distinct groups of customers."[9]

According to Pruitt and Adlin, the use of personas offers several benefits in product development.[10][11] Personas are said to be cognitively compelling because they put a personal human face on otherwise abstract data about customers. By thinking about the needs of a fictional persona, designers may be better able to infer what a real person might need. Such inference may assist with brainstorming, use case specification, and features definition. Pruitt and Adlin argue personas are easy to communicate to engineering teams and thus allow engineers, developers, and others to absorb customer data in a palatable format. They present several examples of personas used for purposes of communication in various development projects.[10]

Personas also help prevent some common design pitfalls. The first is designing for what Cooper calls "The Elastic User", by which he means that while making product decisions different stakeholders may define the 'user' according to their convenience. Defining personas helps the team have a shared understanding of the real users in terms of their goals, capabilities, and contexts. Personas help prevent "self-referential design" when the designer or developer may unconsciously project their own mental models on the product design which may be very different from that of the target user population. Personas also provide a reality check by helping designers keep the focus of the design on cases that are most likely to be encountered for the target users and not on edge cases which usually will not happen for the target population. According to Cooper, edge cases which should naturally be handled properly should not become the design focus.[5]

The persona benefits are summarized as follows:

• Help team members share a specific, consistent understanding of various audience groups. Data about the groups can be put in a proper context and can be understood and remembered in coherent stories.
• Proposed solutions can be guided by how well they meet the needs of individual user personas. Features can be prioritized based on how well they address the needs of one or more personas.
• Provide a human "face" so as to create empathy for the persons represented by the demographics.[5]
• Help support better design choices by limiting the focus of user for the designers.[12]
• Helps understands what motivates audience to learn more about products/service.

While features will vary based on project needs, all personas will capture the essence of an actual potential user.

Common features include:

• Fake name and profile picture
• Basic demographics (age, race, gender, education, marital status, preferred language, etc.)
• Biography containing personal interests, professional goals, and any other relevant information designers should know
• A summarizing quote
• Technology use
• Disabilities, accessibility needs, or challenges
• Opinions and beliefs

Criticism of personas falls into three general categories: analysis of the underlying logic, concerns about practical implementation, and empirical results.[13]

In terms of scientific logic, it has been argued that because personas are fictional, they have no clear relationship to real customer data and therefore cannot be considered scientific.[14] Chapman and Milham described the purported flaws in considering personas as a scientific research method.[15] They argued that there is no procedure to work reliably from given data to specific personas, and thus such a process is not subject to the scientific method of reproducible research.

Other critics argue that personas can be reductive or stereotypic, leading to a false sense of confidence in an organization's knowledge about its users. Critics like Steve Portigal argue that personas' "appeal comes from the seduction of a sanitized form of reality," where customer data is continuously reduced and abstracted until it is nothing more than a stereotype.[16] Critics claim that persona creation puts the onus on designers, marketers, and user researchers to capture multiple peoples' opinions and views into predefined segments, which could introduce personal bias into the interpretation.

Additionally, personas often feature gendered and racial depictions, which some argue is unnecessary and distracts the target audience of the personas from true consumer behaviors and only enhances biased viewpoints.[17] Finally, it is worth acknowledging that proto-personas and personas are often generalized as the same resource, however, proto-personas are a generative tool used to identify a team's assumptions about their target users. Personas, on the other hand, should be rooted in customer data and research, and be used as a way to coalesce insights about particular segments.

In empirical results, the research to date has offered soft metrics for the success of personas, such as anecdotal feedback from stakeholders. Rönkkö has described how team politics and other organizational issues led to limitations of the personas method in one set of projects.[18] Chapman, Love, Milham, Elrif, and Alford have demonstrated with survey data that descriptions with more than a few attributes (e.g., such as a persona) are likely to describe very few if any real people. They argued that personas cannot be assumed to be descriptive of actual customers.[19]

A study conducted by Long claimed support for Cooper, Pruitt et al. in the use of personas.[20] In a partially controlled study, a group of students were asked to solve a design brief; two groups used personas while one group did not. The students who used personas were awarded higher course evaluations than the group who did not. Students who used personas were assessed as having produced designs with better usability attributes than students who did not use personas. The study also suggests that using personas may improve communication between design teams and facilitate user-focused design discussion. The study had several limitations: outcomes were assessed by a professor and students who were not blind to the hypothesis, students were assigned to groups in a non-random fashion, the findings were not replicated, and other contributing factors or expectation effects (e.g., the Hawthorne effect or Pygmalion effect) were not controlled for.

Data-driven personas (sometimes also called quantitative personas) have been suggested by McGinn and Kotamraju.[21] These personas are claimed to address the shortcomings of qualitative persona generation (see Criticism). Academic scholars have proposed several methods for data-driven persona development, such as clustering, factor analysis, principal component analysis, latent semantic analysis, and non-negative matrix factorization. These methods generally take numerical input data, reduce its dimensionality, and output higher level abstractions (e.g., clusters, components, factors) that describe the patterns in the data. These patterns are typically interpreted as "skeletal" personas, and enriched with personified information (e.g., name, portrait picture). Quantitative personas can also be enriched with qualitative insights to generate mixed method personas[22] (also called hybrid personas).

Look up persona in Wiktionary, the free dictionary.

• Cooper, Alan (1999). The Inmates Are Running The Asylum. Sams. ISBN 0672316498.
• Grudin, J; Pruitt, J (June 2002), "Personas, participatory design and product development: an infrastructure for engagement", Participatory Design Conference, Malmo, Sweden{{citation}}: CS1 maint: location missing publisher (link)
• Humphrey, A (2017), Humphrey, Aaron (2017). "User Personas and Social Media Profiles". Persona Studies. 3 (2): 13. doi:10.21153/ps2017vol3no2art708. hdl:2440/123312. Persona Studies, vol. 3, no. 2, pp 13–20.
• Nielsen, Lene (2014), "Personas", in Soegaard, Mads; Dam, Rikke Friis (eds.), The Encyclopedia of Human-Computer Interaction (2nd ed.), Aarhus, Denmark: The Interaction Design Foundation, ISBN 978-87-92964-00-7