Personas - Reconsidered

authors: James Lentz and Mark Marrara

Personas have been a part of the experience designer’s and researcher’s toolkits since Alan Cooper introduced the term more than 20 years ago (Cooper, 1999). They are now pervasively used in design, marketing and product management (Owens, 2017; de Haaff, 2017). and help to design a variety of experiences with products, tools, and services.

Given their popularity, we might expect consensus in their definition and use but this isn’t the case. Many authors have advocated different approaches for persona construction. More importantly, some now question their value (e.g. Price, 2018; Thelwell, 2017; Massanari, 2010; Christensen, 2016). Yet they continue to be a standard part of design practices.

There are as many critiques of personas as there are approaches, yet they tend to focus on isolated issues such whether or not personas should be created in an ad hoc manner or contain fictional details. We provide a deeper examination of the attributes used to define personas, assess whether they are helpful in the design process, and then construct a leaner approach to personas that, as a foundation, communicates contextual information related to goal, job, and skill. By doing so, we unify personas with Jobs to be Done (JTBD) frameworks and story-based scenario approaches. We recommend eliminating all other persona attributes, such as demographics and personal details. Communicating this information in the narrative form of a scenario or story further helps collaborators frame the problem and build cognitive empathy for designers.

The many faces of personas

To identify and evaluate the elements used to create personas we will first briefly define what we mean by a “persona”. For us, a persona is a fictitious representation of a person, composed of a name and zero or more attributes that has a relationship to a product, tool, service or system. By this definition, actors in UML diagrams would not be personas because they lack names. A role would not be a persona because roles are functions performed in a system. However a role could be an attribute of a persona. There are many varieties of personas and some have found it useful to classify them in taxonomies (Peterson 2016 and Nielsen, 2014). We discuss the most common types; however, because many practitioners create mashups of common types, our analysis will focus on attributes.

As noted above, Alan Cooper is usually credited for the basic idea of personas. His persona was to be a fictional person, based on one or more real people using a tool. He argued that designers should target specific imaginary users rather than seeking to accommodate everyone. By doing so, the design might capture, say 80%, of the target audience without introducing the complexity resulting from addressing the needs of the other 20% (Cooper, 1999).

Kim Goodwin, a director in Cooper’s consulting practice, elaborated and refined Cooper’s concept of personas (Goodwin, 2018). In their scheme, personas are defined using observations and/or interviews. They include the following empirically identified attributes:

• Skills
• Attitudes (possibly)
• Environments
• The course of daily activities
• Goals

In addition, they advocated adding a few fictional personal attributes in order to make the persona seem more realistic and thereby generate empathy with designers. Lene Nielsen’s (2014) personas are similar to Cooper’s and Goodwin’s but much more strongly emphasizes adding fictitious personal detail in order to achieve a strong sense of realism. In one example, she described a persona with more than 30 attributes, including not just the name, an image, education and place of employment but also how old the persona was when she married, her husband’s name, how frequently her adult children come to visit and why they visit (her cooking). In this very extensive persona bio, Nielsen also includes the persona’s attitudes about new technology (skeptical), a need for email receipt confirmation, confidence in her technical skills (low). She also describes her persona’s daily experiences and lists tasks involved in her job

Nielsen states that these details improve empathy for designers and reduce tendencies to stereotype users. She further claimed that behavioral attributes provided in personas fail to consider the whole person.

Another approach, pastiche personas, uses well-known fictional characters (e.g. Bart Simpson) to explore design issues (Blythe and Wright, 2006). Pastiche personas are discussed in the context of pastiche scenarios which are well known stories or settings (e.g. George Orwell’s 1984). The purported value of pastiche personas and scenarios is asserted to be their tendency to provoke lively design discussions. Whether or not they are intended to, the attributes of well-known characters implicitly influence the designer’s perspective of the persona. For example, Bart Simpson’s penchant for risk taking and causing trouble are attributes that are not separable from Bart Simpson as a persona.

Not all persona approaches stress the use of fictional attributes. For example, behavioral personas communicate what people do rather than who they are (Bartel, 2016). Defined by the activities that users engage in or the tasks they perform, behavioral personas can identify and describe behavior in terms of the function of a person in an organization or context (Bartel, 2016). Peterson (2016) sees behavioral personas as means of grouping people based on common goals, motivations and behavior patterns. Others define them in terms of dispositional attributes such as likelihood to ask for help in challenging situations (Mesibov, 2019). Ben-Menachem (2016) elaborates the dispositional approach and derives personas from patterns of values of bipolar attributes on semantic differential scales.

Many persona approaches include demographic data as the foundation for a persona description. These approaches rely on clusters of demographic attributes collected in interviews or surveys, and the demographic attributes tend to be persistent features of individuals such as age, gender, income, education, and so forth. This approach is similar to demographic market segmentation (e.g. Yanelovitch, 1964).

Demographic persona attributes are assumed to correlate with usage or purchasing behavior. This approach also yields highly data-driven personas that, due to the nature of demographic data, are relatively unbiased by prior assumptions. Demographic attributes help describe the potential audience for a product, but demographic attributes alone do not provide adequate details for understanding the user’s challenges or develop designer empathy.

Persona Attributes

As persona approaches evolved, the types of attributes used to create them has grown. Once they consisted of a few research-based details with some fictional details to liven them up. Now, it is common to see personas include demographic data, behavioral data, and even some attitudinal descriptions to suggest how a person would react in scenarios. Are there benefits to adding various types of attributes to personas? For instance, do more persona attributes produce better discussion, less churn, and stronger designs? We suggest that they do not. More often, unnecessary attributes cause churn and distract from understanding the scenarios and context needed for design. We will review the types of attributes frequently added into personas and follow this with a discussion of problems commonly encountered with these persona attributes.

Fictional Personal Attributes

Most persona models include some attributes that are invented rather than identified empirically. These have at least three functions:

• Identification: The name and an image of an avatar label it so that it is easily differentiated from other personas. This is essential when designs involve multiple personas.
• Memorability: The name and image also help make it easier to remember and recognize a persona. Other details facilitate storytelling. These narrative attributes (Lentz, 2019) can include personal details, activities and scenarios. Narrative formats themselves greatly enhance understanding and remembering (Bartlett, 1920; Bower and Clark, 1969).
• Empathy: perhaps the most often cited reason for including personal details is the generation of empathy. This is a complex topic that we will discuss in detail.

The argument in favor of including fictional personal details in personas asserts that these details “bring the persona to life” (Goodwin, 2018). Essentially the claim is that the more real that personas appear, the better job the designer will do for them. While we agree that details that support story lines help us to identify, remember and understand user activities; however, we question the claim that fictional personal details generate empathy that is useful for design. We will address and discuss empathy more deeply below in the Common Problems with Persona Attributes section, below.

Aspirational Attributes

Aspirational persona attributes are qualities that describe an anticipated future user. These attributes are designed to address a limitation of data-driven personas. Data-driven personas are based on research with existing user experiences. These experiences were the result of a design created in the past that possibly was created in response to even earlier design experiences. Designers implicitly forecast how the legacy product user will experience the new product. They don’t always take into account how the users may have adapted to and are invested in the current experience. They may not accurately predict how the user will react to the new experience.

This should be a concern when the experience changes radically. For example, consider how useful research on the use of corded landline phones would have been in predicting the use of modern mobile smart phones. It seems unlikely that research on these tethered phones would have predicted that highly mobile phones would cause tens of thousands of deaths as a consequence of distracted driving.

Furthermore, when researching existing users, those users typically will discuss needs in terms of pain-points within the current experience. This cuts two ways. Although it helps to identify what needs to change, it also frames design problems in terms of legacy experiences. This can make it difficult to re-conceptualize designs and jobs, leaving alternative design paths unexplored. Some of these design paths may be far superior to the current design. Rather than focusing on the users that a product currently has, it is possible to define personas based on predicted users, jobs and even markets. A case in point is the “citizen developer” (e.g, Hinchcliffe, 2016) or “end-user developer” (e.g. Liberman, 2006).

The citizen developer persona came about because skilled programmers are expensive; traditional development cycles are slow; and products developed by nonusers often fail to satisfy all requirements. In theory, businesses would be more agile if users could create their own tools rather than levying requirements on trained software developers. These so-called citizen developers would be able to recognize the inefficiencies in their own work, and then create or modify their tools as needed. This is an old idea and many no- or low-code platforms have been brought to market to meet this need. In this case, the need was identified before the user type existed.

Aspirational persona attributes can be based on observations of existing usage but ultimately, they are forecasts. They might also be based on observations of people who aren’t currently using the type of products being designed. Aspirational persona attributes can be valuable because if successfully used, they can help to anticipate usage of radically different technologies. However, developing experiences for aspirational personas is far riskier than improving the experiences of existing users, as the expected market may not exist now or ever. The target user persona may be misidentified or forecast incorrectly. Google-glass is a commonly cited example of a product for a user who doesn’t exist (e.g. Morgan, 2019) or a product created for the wrong user (Levy, 2017). There are legions of examples of such mis-targeted products (Microsoft Bob, Apple Newton, the Edsel, etc.).

Demographic Attributes

Demographics are easy to collect in a survey or interview and the responses are easily coded and summarized. Researchers collect demographic attributes because they implicitly expect them to correlate with product experiences, usage or purchase.

Demographic attributes have been criticized by advocates of the Jobs to Be Done (JTBD) product design and marketing philosophy. Their objection boils down to two simple observations (e.g. Christensen et al. 2016):

• Correlations do not determine causation — my age, income, the brand of car I drive, and my marital status do not cause me to subscribe to one streaming service versus another.
• Motivations determine causation — I purchase a product so that I can achieve a particular outcome. I will buy an electric drill with a built-in level so that it can help me drill a hole parallel to the ground.

In addition, demographic attributes don’t appear to inform design in any but the most trivial of cases. We will concede that the design of the My Little Pony: Music Princess video game has likely been informed by awareness of prepubescent girls and the design of the modern Mini Cooper and second-generation VW Beetle were informed by awareness of nostalgic Baby Boomers. However, the design influences don’t go any further than particular aesthetic directions to attract a target market. They tend to be useless for the majority of product design scenarios.

Role attributes

In business enterprises, what a person does is mostly defined by their position, responsibilities or function. These are referred to as roles.

Unfortunately, the term “role” has different connotations in product design and development. One refers to a behavioral mode. I can assume the role (mode) of writer when using a word processor but that does not mean I perform the role (organizational function) of technical writer. Unless qualified, we will use the term in the second sense, an organizational role.

In addition, roles can be fluid. People change roles during their career or within the life cycle of a single project. They aren’t fixed attributes. The work done by the role is more stable than the identity of the user and therefore should be more valuable for design activities

Organizational roles may have many different attributes such as job title, mission, knowledge, skills, collaborators, environmental aspects, activities, work intensity and stress, focused versus interrupt driven, degree of specialization, and other aspects of work inside of an organization (Adkissen, 2019; Canziba, 2018; Nielsen, 2014). An organizational role encompasses a set of responsibilities into a single functional identity. These responsibilities are activities that one or more persons perform. Therefore, an organizational role can be thought of as defining a group of behaviors.

Many organizational roles are well known and are highly consistent from one enterprise to another. Including the role in a persona effectively encapsulates a great deal of information about behavior, yet the role alone does not provide adequate detail of the actual work to be done and challenges experienced along the way. It is necessary to enumerate the responsibilities, activities and tasks performed by a persona with a specific organizational role as they relate to an experience being designed to provide adequate detail needed to support design activities.

Goal attributes

Many persona descriptions include one or more goals that the persona is assumed to have. “Goal” is also an overloaded term. A goal can be a personal goal (leave work on time, be promoted, buy a new car, etc.), a goal defined by the organization (complete the financial report on time), or the end-state of a particular activity, task or subtask (fill the car’s gas tank).

Persona authors often list personal goals in their persona definition. These are likely specified in the service of empathetic design. However in enterprises, the harsh reality is that personal goals are at best secondary to organizational goals. Enterprises hire people with specific skills for roles or positions, assign them responsibilities and projects in order to support organizational goals. Enterprise goals and worker goals can be in opposition (the environmentalist working in the petrochemical industry) or consonant (the volunteer working in a soup kitchen). They often have nothing to do with each other.

The products that the enterprise software designer designs exist to help employees achieve organizational goals. Moreover, employee users may sometimes influence purchases but ultimately their likes are subordinate to the goals of the organization. Often the decisions about which products are purchased are made by people who will never use them without even consulting the prospective users. Therefore, it is typically unreliable to list and treat personal goals as a driving factor of behavior and usage for a persona in an enterprise environment.

Dispositional Attributes

Dispositional Attributes of personas include traits such as attitudes that might influence the user’s relationship with the product. Examples include:

• Confidence (or lack thereof) in using new technology
• Orientation toward detail
• Conscientiousness
• Privacy concerns
• Security concerns
• Motivation to learn

Dispositional attributes are often vague, context-dependent and transitory. A user of a product will have very different attitudes when they are using it for the first time compared to when they become skilled at it. Highly-skilled users may even demonstrate positive attitudes toward a product that took them months to learn — a phenomenon that we should call the Difficult Product Stockholm Syndrome. A person may be confident about using some types of technology but intimidated by others. Additionally, many dispositional attributes, such as privacy concerns, security concerns, and motivation to learn, will often depend on the context of use. Other dispositional attributes are difficult to define and measure (e.g. detail-oriented and conscientiousness), and the inherent ambiguity within these dimensions leads to needless churn. In a few cases, attitudinal issues may be important — security or privacy concerns might call for specific design features; however, many soft attributes often create just noise without design implications.

Universal Attributes

Ostensibly, attributes are supposed to differentiate personas. However, some commonly listed attributes are more or less universal and consequently fail to differentiate. For example:

• Has more work than time
• Dislikes reading documentation
• Has invested time in learning how to accomplish tasks
• Doesn’t like replacing a familiar experience with an unfamiliar experience
• Dislikes repetitive tasks
• Values privacy and security
• Enjoys the feeling of closure upon completion
• Enjoys explicit confirmation
• Hates making mistakes
• Hates losing data

Ubiquity doesn’t mean that universal attributes have no place in design. They can be useful to remind designers about general user qualities. However, they probably belong in a different kind of supporting design artifact similar to a “user’s bill of rights” (e.g. O’Reilly, 2009).

Work-related attributes

Some attributes found in persona descriptions are not properties of people. They instead have to do with the work that people do. Work-related attributes are closely associated with organizational roles and goals. Roles determine the work and the work defines the goals.

Motivational attributes of work: As noted above, the Jobs to Be Done (JTBD) approach arose as a reaction against the use of demographic personas and attributes in order to foster innovation in product concepts (Christensen, 2016; Ulwich 2016). Unlike persona advocates, the originators of JTBD hailed from business schools, product management and marketing. They were primarily concerned with what causes a person to buy a product or in their terminology, “the job the product was hired to do”. The JTBD approach is based on the realization that features of the person are frequently less important than the problems (or jobs) they are trying to solve.

This insight poses some critical questions for design. Can one really successfully and efficiently design a product without understanding what people will do with it and why? Or without deeply understanding the motivating problem and challenges to be solved by the product? Understanding strengths and weaknesses of current products with respect to the work being done is critical for finding opportunities to innovate.

Work-related attributes include the outcomes sought (i.e. goals), the context or situation in which the job takes place, and some notion of a bridging function between the situation and the outcome. Ulwich (2016) referred to the bridge between situations and outcomes as steps which are really no different from “activities”. Activity-centered design (Norman, 2008) aligns well with the notion of job steps.

The focus on outcomes and contexts is valuable because it de-emphasizes characteristics of the person and by doing so becomes less discriminatory and more inclusive. It’s important to stress that everyone doesn’t need to have the ability or desire to perform the same jobs.

Constraining attributes of work: Some persona descriptions mention aspects of work that constrain or influence the persona’s behavior in some way or another. These may be inherent aspects of certain jobs or design challenges. Examples include:

• Locus of control — Does the person control the ordering and pace of the work that they perform or does the work drive the person?
• Workload
• Susceptibility to interruption
• Skill requirements
• Organizational Environment

Some constraining attributes of work can be helpful in setting context and aligning stakeholders on the work being done. For example, understanding how the work is started and handed off to collaborators or how newer employees learn the work to be done can help designers to further understand the problem space.

Common Problems with Persona Attributes

The empathy problem

As noted previously, a claimed benefit of providing rich and detailed personas is the creation of empathy on the designer’s part. As designers create more empathy towards the potential user, they will construct better and more meaningful solutions to further improve their users’ lives. This assumed benefit warrants further discussion.

One problem with empathy is that the term is used, misused and confused without a careful consideration of what it means. First, empathy is often confused with sympathy. Empathy has to do with co-experiencing the mental state of another person. Sympathy has to do with an emotion felt when thinking about the circumstance, usually unpleasant, of another person. It is possible to feel sympathy for a person who nevertheless is perfectly content with their current situation.

Sympathy aside, psychologists and philosophers make distinctions between different kinds of empathy. Furthermore, they don’t often agree about how many kinds there are. Nevertheless, they often distinguish between affective and cognitive empathy. Affective empathy is the sharing of an emotional state — “I feel your pain”. Cognitive empathy is the experience of imagining another person’s state of mind (Stueber 2019). For example:

Sympathy: I feel sorry for John because he has to use the product.

Affective empathy: I feel John’s delight (or pain) when I see him using the product.

Cognitive empathy: I imagine myself as John using the product.

Depending on how the designer or researcher interprets “empathy” very different outcomes might result. At a minimum, researchers, designers and stakeholders should understand what kind of empathy they seek to develop in their personas and the outcome they expect to achieve.

Those who believe that empathy leads to good design assert that when a designer reads personal details about a persona, she finds it easier to think empathically. Although these details about the persona may make it seem “real”, the extent to which a cartoon character with accompanying bullet points is capable of generating either affective or cognitive empathy in the same sense that a living breathing person can is questionable. Furthermore, even if they do, how is the empathy altered by whether those details are consonant or dissonant with those of the designer herself? The effect of similarity between empathizer and “empathizee” is an active topic of research in social psychology. Rather than wading into this tall grass here, it is sufficient to say that similarities and differences do have an effect on empathy created. Adding multiple details to personas only serves to muddy the waters.

Even if a persona allows a designer to assume the perspective of a user, this only begs the question of whether or not being empathetic produces better designs. For instance, Eyal, Steffel and Epley (2018) conducted a series of experiments to answer a similar question. They found that giving instructions to take the perspective of another person failed to improve predictions of emotions, opinions and preferences and were even a little worse than control participants who weren’t given these instructions. Moreover, this was true even when the target perspective was that of a significant other.

What did help was to ask participants to get the perspective of the other person before making predictions. This should be obvious. However, they also found no difference between perspective getters and takers in their confidence in their predictions. In other words, perspective-takers overestimated their ability to make predictions.

More empirical work is needed, but we know enough to question the assumed efficacy of emotional empathetic design. There is no evidence that it works and some evidence that it doesn’t. Adding rich detail to personas provides an opportunity to enliven the persona description but risks unknown influences from designer biases. On the other-hand, cognitive empathy, or understanding the experience of the user interacting with a product, may help the designer create a better experience. Understanding a user’s current experience in most cases will not require personal persona details.

The average user problem

Most approaches to persona creation assume that, at some point, research on potential users is conducted in order to base personas on real data. Persona attributes typically summarize the data by listing those that show up most frequently. This makes intuitive sense, but there are problems with this approach.

There is often an implicit assumption that it is best to design for an ‘average’ or ‘most common’ user. In reality, this person may not be representative because attributes may not covary with each other (Price, 2018). This approach also stereotypes users by ignoring their variability. When designers focus on stereotypical personas, they optimize designs for a few users while ignoring the natural variability. In effect, they create designs that discriminate. To avoid this, Price (2018) has argued for dispensing with individual personas and design for “persona spectrums” to accommodate variation.

That researchers would present models of “average” users is remarkable and not in a good way. It runs counter to inclusive approaches like accessible design and many principles accepted long ago in anthropometrics, ergonomics and human factors (Lentz, 2019). It is also a self-defeating market strategy. Why design for a smaller audience when you can have a larger one?

The attribute noise problem

Identifying and including many attributes in a persona is often assumed to enhance the predictive power of the persona. If we just collected data from a large number of potential users on a huge number of personal variables, we could predict with perfect accuracy how many people would choose one design over another. You might think of this as the big data theory of product design, where good design results from gathering more data. However, this more-is-better assumption has problems. As previously discussed, the assumption that persona attributes create useful cognitive empathy is questionable, and this remains true regardless of the number of attributes specified. Adding more attributes can create noise. In addition, selecting attributes for inclusion in a persona profile creates opportunities for injecting bias into the design.

Finally, although behavioral attributes may be more relevant for interactions with technology, their implications for design may be obscure. Dispositional attributes can be vague or more closely associated with personality traits than a user’s interaction needs. Universal attributes by definition don’t differ between personas and therefore are redundant and useless for persona differentiation.

To summarize, many attributes that often appear in persona descriptions don’t perform a useful function. Unfortunately, many persona authors assume that a large number of attributes in their personas demonstrates thoroughness. However, if those attributes don’t help the designer to design, then they are only distracting the design team. It forces designers to separate the design wheat from the persona chaff. It does not help the designer form the cognitive empathy required to understand what it is like to use the design.

A lean approach to personas

Many have recognized these problems and some have called for abandoning personas altogether. However, as much as we would like to kill them off, some of the details embedded in persona models can inform design. We just need to make personas more useful and usable.

To do this we believe that personas must be simplified and reframed. Rather than being elaborate, richly researched proxies for actual human beings, personas should be viewed as concise artifacts that serve to define reliable associations between individuals, situations, goals, and activities. When these are framed in narrative scenarios, personas provide the cognitive empathy needed by designers to solve user problems.

A good persona model follows the rule that less is more. When a persona has minimal but targeted detail, it will facilitate communication between designers and stakeholders. The set of personas related to a design will be easy to remember and keep straight. With fewer features and nuances there should be fewer personas to manage, hopefully reducing the need for inflexible and bureaucratic persona libraries for large projects and enterprises.

Most importantly, these minimalistic personas will be more inclusive because they serve as stand-ins for a greater variety of people. They can be used to encourage designers to create experiences that are open to more users. They lend themselves to ad-hoc discussions and design explorations (e.g. “How can we design the course catalog to satisfy both lackadaisical and diligent students without adding additional complexity?”). They also support aspirational personas for products designed to rely less on skills and knowledge.

Our persona model is represented graphically in Figure 1, below. For us, a persona is an organizing mechanism referenced by an identity. It consists of a person and his or her jobs. For design, the jobs of interest are those facilitated by a product (tools or services). When situated in a business enterprise, it is often useful to also understand the organization that determines jobs and products. We will describe these objects in greater detail.

Person: The person consists of an identity (name and optional image). Its most essential attributes are responsibilities, abilities, and goals. Responsibilities inform what jobs the person performs and abilities define prerequisite skills or knowledge for performing the jobs. Goals are objectives derived from responsibilities.

This model acknowledges that people have personal attributes, however, they are not related to the jobs performed and therefore need not be described. Universal attributes that are common to all potential product users include, for instance, perceptual abilities, reaction times, intolerance for slow system response times, feelings of closure upon task completion and so forth. These attributes are sometimes critically important; however, because they do not distinguish between personas they may be treated as supporting information to a set of personas.

Job: A job reflects the work done in the conduct of the person’s responsibilities. We believe that understanding and communicating jobs is more critical than understanding many other additional details about personas. We use the term “job” here in the same way that JTBD advocates do. A job encapsulates the goals (outcomes) that arise in various contexts (situations) and the activities performed to realize those goals (Ulwick, 2016).

Coincidentally, job situations, activities and outcomes map directly onto the structure of a user story or narrative. A story consists of a situation, action, and resolution. In job terms, the situation is the setting, the activities are the action, and the outcome is the resolution. Stories are a natural, efficient, memorable, and empathetic communication method in design, and as a result, we see these as an important part of a lean persona.

The narratives of as-is and to-be experiences are so important that the story can be used to define the persona rather than the other way around. The story should guide the selection of the important attributes to include in communicating the persona.

Jared Spool (2018) demonstrated how well-written scenarios (i.e. stories) can convey the context for the work, the type of work, and the challenges that arise — an efficient way to communicate essential design problems while building cognitive empathy in designers. All of this can be achieved with little more than the name of the persona.

In Spool’s stories, details are provided in an introductory paragraph or two. For example, in an air travel check-in scenario, he introduces his persona as traveling with an infant and a mobility-challenged elder relative. This defines part of the situational context in a way that stakeholders can easily imagine and empathize with the various demands placed on the traveler as he checks in. Note that the important aspects of empathy here are cognitive rather than emotional. The fact that the traveler’s attention is divided has serious design implications.

Figure 1. Conceptual model of personas and design context

Product: The product is the thing being designed — a tool or service. It exists to help the persona accomplish her jobs. In an enterprise context, the product helps the persona satisfy organizational and individual jobs. In scenarios outside of work, the product still enables the person to satisfy their jobs, with the subtle difference of the jobs not being defined by the organization and instead the individual person.

Organization: The organizational layer is specific to products designed for business enterprises and can be dispensed with when designing consumer products. It defines the social context that the work is performed within. Enterprises have objectives. For business enterprises these include profits, return on investments, market share and so forth. Non-profit enterprises also have objectives, usually dealing with some form of social good.

Organizational objectives are achieved by organizational jobs. Organizational jobs have requirements that define completion or success criteria, and these jobs are performed by organizational roles (CEO, marketing director and so forth). Describing the requirements for the organization jobs as part of the persona narrative is useful to ensure designers fully understand the nature of the work and success criteria of the organization.

Conclusion

Since their inception, personas have developed in different directions. One commonality in their maturation is the inclusion of many different types of attributes to describe and enliven the persona. Whether personal, demographic, or aspirational, for instance, the attributes added to personas were thought to provide additional necessary detail to better understand the person being designed for and build empathy for this person. We suggest that these details do not create the cognitive empathy desired on the part of designers nor do they create a deeper understanding of the user and their abilities, goals, and jobs. Some attributes, like fictional attributes, occasionally work against building a deeper understanding of users and their abilities.

We offer a leaner approach to personas that moves away from the traditional persona model that calls out various demographic data and personal characteristics to describe potential users. We instead encourage building a narrative-based scenario that describes the person in reference to their responsibilities, abilities, and goals.

Personas can be documented by first providing an introductory narrative description of the person, then the person’s jobs that they are performing, the product (tool or service) that assists in performing the jobs, and when operating in a business enterprise, some aspects of the organization that influence the job. When designing outside of a business context, including environmental details that influence the job can also be beneficial for setting context in the narrative.

Presenting the jobs in narrative form increases effectiveness of presentation and cognitive empathy. Notably including details of when (the situation) the persona works (the activity) so that a result (the outcome) occurs starts to unify this persona approach with the JTBD framework.

This approach builds a persona that provides a much more useful description of a person, their work to be done, and the context in which the work is done. Using a narrative to construct the persona also naturally builds cognitive empathy for designers through the use of storytelling to set context and provide details. When a persona is involved in more than one scenario in a design effort, the same introductory paragraph of the persona can be reused where applicable, although the details in the narrative that describe the job and related outcomes would differ. This eliminates the need for personas as separate design artifacts that list personal attributes and demographics, by instead describing the person as part of a set of user stories that set context, communicate the problems, and build cognitive empathy.

References

Adkisson, H. (2019, October 5). Creating Role-Based Personas for the Enterprise. Medium. https://medium.com/@hpadkisson/creating-role-based-personas-for-the-enterprise-6471e7060d82

Bartel, D. (2016, August 9). Do you know your Users? Introducing Behavioral Personas. Medium. https://medium.com/@taaminsights/do-you-now-your-users-introducing-behavioral-personas-8668f56b97d8

Bartlett, F.C. (1920) Some Experiments on the Reproduction of Folk-Stories, Folk-Lore, 31: 30–47. http://www.bartlett.psychol.cam.ac.uk/SomeExperimentsOn.htm

Blythe, M., & Wright, P. C. (2006). Pastiche scenarios: Fiction as a resource for user-centered design. Interacting with Computers, 18(5), 1139–1164. https://doi.org/10.1016/j.intcom.2006.02.001

Browne, J., Manning, H., Dorsey, M., Drego, V. L., Beckers, A., & Catino, S. (2009). Assumption Personas Help Overcome Hurdles To Using Research-Based Design Personas. Forrester. https://www.forrester.com/report/Assumption+Personas+Help+Overcome+Hurdles+To+Using+ResearchBased+Design+Personas/-/E-RES53874

Bower, G.H. & Clark, M.C. (1969). Narrative stories as mediators for serial learning. Psychonomic Science, 14(4), 181–182.

Canziba, E. (2018). Hands-On UX Design for Developers: Design, prototype, and implement compelling user experiences from scratch. Packt.

Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016, September 1). Know Your Customers’ “Jobs to Be Done.” Harvard Business Review, September 2016. https://hbr.org/2016/09/know-your-customers-jobs-to-be-done

Cooper, A. (1999). The Inmates Are Running the Asylum (1st ed.). Macmillan Publishing Co., Inc.

de Haaff, B. (2017, December 6). How Product Managers Quickly Define Customer Personas. HuffPost. https://www.huffpost.com/entry/how-product-managers-quic_b_10530850

Eyal, T., Steffel, M., & Epley, N. (2018, October 9). Research: Perspective-Taking Doesn’t Help You Understand What Others Want. Harvard Business Review. https://hbr.org/2018/10/research-perspective-taking-doesnt-help-you-understand-what-others-want

Goodwin, K. (2018, September 27). Getting from Research to Personas: Harnessing the Power of Data. UX Articles by UIE. https://articles.uie.com/research_to_personas/

Hinchcliffe, D. (2016, April 18). The advent of the citizen developer. ZDNet. https://www.zdnet.com/article/the-advent-of-the-citizen-developer/

Nielse, L. (2014). Personas (2nd ed.). Interaction Design Foundation. https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed/personas

Lentz, J. (2019, April 25). Should you design for People, Personas, Activities or Jobs? https://medium.com/@jimlentz/should-you-design-for-people-persons-activities-or-jobs-652d5e396e6d

Levy, S. (2017, July 18). Google Glass 2.0 Is a Startling Second Act. Wired. https://www.wired.com/story/google-glass-2-is-here/

Liberman, H., Paternò, F., Klann, M., & Wulf, V. (2006). End User Development: An Emerging Paradigm. In End User Development (Vol. 9, pp. 1–8). Springer.

Massanari, A. L. (2010). Designing for imaginary friends: Information architecture, personas and the politics of user-centered design. New Media & Society, 12(3), 401–416. https://doi.org/10.1177/1461444809346722

Morgan, B. (2019, September 9). 10 Recent Product Design Failures And What We Can Learn From Them. Forbes. https://www.forbes.com/sites/blakemorgan/2019/09/09/10-recent-product-design-failures-and-what-we-can-learn-from-them/

Norman, D. (2008, November 17). Ad-Hoc Personas & Empathetic Focus. Jnd.Org. https://jnd.org/ad-hoc_personas_empathetic_focus/

Norman, D. (2005, July-August). User centered design considered harmful. Interactions.
https://dl.acm.org/doi/10.1145/1070960.1070976

O’Reilly, D. (2009, December 29). Time to update the software user’s bill of rights. CNET. https://www.cnet.com/news/time-to-update-the-software-users-bill-of-rights/

Owens, S. (2017, March 30). Design Personas vs Marketing Personas: They. Are. Different! Medium. https://medium.theuxblog.com/design-personas-vs-marketing-personas-they-are-different-2724992acc78

Peterson, M. (2016, October 10). The Problem with Personas. Medium. https://blog.prototypr.io/the-problem-with-personas-82eb57802114

Price, M. (2020, April 9). Kill Your Personas. Medium. https://medium.com/microsoft-design/kill-your-personas-1c332d4908cc

Spool, J. (2018, September 11). When It Comes To Personas, The Real Value Is In The
Scenarios. UX Articles by UIE. https://articles.uie.com/when-it-comes-to-personas-the-real-value-is-in-the-scenarios/

Stueber, K. (2008). Empathy. In Standford Encyclopedia of Philosophy (Fall 2019). https://plato.stanford.edu/archives/fall2019/entries/empathy/

Thellwell, C. (2017, April 12). Are personas ruining your product? https://www.invisionapp.com/inside-design/personas/

Ulwick, A. (2016). Jobs-to-be-Done. Idea Bite Press. http://jobs-to-be-done-book.com/

Yankelovich, D. (1964, March 1). New Criteria for Market Segmentation. Harvard Business Review, March 1964. https://hbr.org/1964/03/new-criteria-for-market-segmentation