Definitions, Types, Goals , Applications, Creation, Success and Failure of Personas in Product Design

Creating personas has become a standard practice within many human-centered design disciplines according to the Interaction Design Foundation. Persona is basically a tool to personify research findings and certain trends in target customers for a better understanding of product stakeholders.

I found user personas one of the most controversial topics of UX design. Some designers consider it as a must-to-have for the design process, some hate it and don’t see any benefits in defining a persona and some have no idea whether it is good or bad, they just put a persona between their design artifacts to have one! But why is it like this? I decided to dive deep into the existing research works about persona and write up my own takeaways.

My main takeaways that I like to share before getting to details of personas are:

• A persona is just a tool that helps product teams understand and empathize with their target user groups. Like any other tool, it must be used for the right purpose and in a right way. (You cannot expect to twist a screw with a jigsaw and enjoy the process!)
• Persona must be representative of your target user groups, not a single imaginary user. Make more personas if you don’t find one helpful.
• Consider persona spectrum achieve an inclusive design.
• Consider personas as alive as your users. Their expectations, needs and emotions may change during the life of your product.
• The information of the persona artifact must root in robust research work and reflect the findings of user interviews, otherwise, no one will take it seriously!
• Don’t put irrelevant information about users if that information doesn’t help other team members to understand and empathize with your users.

Methodology

For this research, I explored more than 10 resources including, books, videos, articles, and blog posts about personas. I started categorizing my findings and notes and was able to put everything in one of the following categories:

• Definition of persona
• Types of persona
• The goal of creating a persona
• Applications of persona
• Creation of persona
• Success of persona
• Failure of persona

Persona Definition

There are many definitions of persona in various formats but the common concept in all of them is that persona is the reflection of target user needs, characteristics, wishes, and behaviors. However, there are subtle differences in definitions that I like to highlight here.

NN/g in What are personas and why should I care? Considered persona as “subset of target audience” or “smaller segments of target audience” in Creating personas is like sorting rocks, and it is where we can find the difference between NN/g’s definition and other resources. Alan Cooper in his famous book, The Inmates Are Running the Asylum, defines persona as “a precise definition of our user”. Ergomania UX, defines personas as “archetypical users” and the Interaction Design Foundation, defines personas as “fictional characters that represent the different user types”.

There are probably many other approaches in defining personas but I think accepting that each persona is representative of a subset of target users, as NN/g suggests, can bring better insights to the table. The basic takeaway of selecting this definition is that you would probably consider defining more than one persona (for each identified subset) for the product and consider the effects of your decisions on each persona.

Types of Persona

Lene Nielsen, defines four types of personas based on the value that they can add to the design process:

• Goal-directed personas: that aim to examine the process and workflow that your user would prefer to utilize in interacting with the product or service.
• Role-based persona: that focuses on the user’s role in the organization. It is also goal-directed and focuses on behavior.
• Engaging persona: that aims to engage designers into the lives of their users by considering emotions, psychology, background, and behaviors. This type can incorporate both goal and role-directed personas as well.
• Fictional personas: are not made based on user research and the primary goal of using them is to allow for early involvement with potential users in the design process.

Federico Francioni in his article, The upfront guide to design inclusive personas, talks about two major types of personas:

• Inclusive personas: that is driven by behavioral and physical characteristics of users and focuses on belonging (the intersection of Inclusion, Diversity, and Equity- read more about belonging at this article)
• Functional personas: that is driven by function, role or workstyle and captures gaps to solve needs of different groups and aims at improving specific journeys

Ideally, you have to identify your user segments and understand what type of persona you need for each segment and define your persona and then start working on your persona spectrum to have an inclusive design output that is responsive to users’ needs and desires. (To learn more about the persona spectrum read pages 104–109 of Mismatch by Kat Holmes.)

The goal of a persona

The goal of a persona can be different from each stakeholder’s perspective. Dan Olsen in his book, The lean product playbook, considers the persona as a company-wide tool whose goal is “to ensure that everyone in the company who is involved in the product is aligned with the same customer”.

Kat Holmes in Mismatch considers persona a tool for designers and engineers that “reminds them that they’re building solutions for someone other than themselves.”

NN/g considers persona a team-level tool that “propels the team to make informed decisions at every step of project development” and brings focus to the team.

Lastly, the Interaction Design Foundation considers the purpose of creating personas “helping to understand users’ needs, experiences, behaviors and goals.”

Base on all my findings, a well-articulated persona can be considered:

• A communication tool for aligning stakeholders to the users
• A tool to remind designers and engineers that they are not building for themselves
• A tool to minimize the uncertainty of trying to understand large groups of people
• A propelling tool for the team to make informed decisions
• A tool that brings focus to the team when it comes to users
• A tool to understand users’ needs, experiences, behaviors, and goals

Applications of Persona

The main question of this part is : When do we need to define a persona? and I found different answers to this question through my studies:

• When you want to get a very deep understanding of target audience to create a user-centered product (NN/g)
• When you want to have a vehicle for storing and communication information about people (NN/g)
• When you want to give your team very specific people references and give your team a design target that everyone can focus on (NN/g)
• When you need a reference point for making certain business or marketing decision (Ergomania UX)
• When you want to provide meaningful archetypes which you can use to assess your design development against (Interaction Design Foundation)
• When you want to ask the right questions and answer those questions in line with users you are designing for (Interaction Design Foundation)
• When you want to define persona spectrum and create inclusive designs in repeatable ways (Mismatch)

Creating Persona

Stu Church, in his informative article, Creating objective personas with multiple correspondence analysis, explains a methodological approach for creating personas that I found very interesting and can be considered a successful approach in creating personas.

Among various recommendations about creating personas, I like to spot on the following:

• The process of creating a persona is only about identifying and honing in on those attributes that impact experience then finding the big trends and patterns among these experiences (NN/g)
• Personas are generalization of gathered qualitative data about users’ attribute not an exact science (It is a best guess about target users) (NN/g)
• Understand about stakeholders’ goals first, then start creating a persona. Don’t create it alone and deliver to the team but get stakeholders’ buy-in in the creation process. (NN/g)
• Personas should fit on a single page and provide a snapshot of the customer archetype that’s quick to digest (Dan Olsen)
• No one starts out with a robust and honed persona. It must be the result of numerous rounds of iterative customer discovery. (Dan Olsen)
• Persona is a model of your users at a particular point in time. It may have some longevity but must always be challenged. (Stu Church)
• Leverage any existing functional persona to prove/disprove your hypothesis, test your assumptions and get better confidence in the inclusive personas you’re building. (Federico Francioni)
• Be aware of the confirmation bias in creating personas. Personas could arise as a sort of self-fulfilling prophecy rather than an objective posthoc analysis of the qualitative insights gathered. (Stu Church)

Successful Personas

Dan Olsen claims that a good persona “empowers everyone on the team with the same solid foundation of information and reasoning”. He believes that personas should make the results more congruous and additive instead of discordant and counterproductive. A useful persona should be pragmatic and provide useful information that can help inform product design decisions.

Alan Cooper believes that successful personas represent clear, evidence-based, behavioral segments of an audience and can be widely shared and used to elicit empathy and inform design decisions.

Finally, a successful persona should be detailed enough to conjure empathy but does not contain information irrelevant from the given project.

Persona Failure

There are some cases that the creation of personas might not help the product team and turn out to be a counterproductive artifact that no one is willing to use. The existence of any of the following conditions might end this situation:

• Lack of understanding what personas really are
• Inaccurate expectations of how personas really work
• Being uncertain about how persona can be used in the project
• Researchers create personas in private and deliver them to people to use
• Lack key information, be poorly written or based purely on speculation (Dan Olsen)
• Contain too many superfluous details that don’t add value (Dan Olsen)
• Lack of important variables changed market conditions, or shift in user expectations and behaviors (Stu Church)

It is important to have a fair expectation of personas to prevent improper usage. Creating personas cannot substitute talking to customers on an ongoing basis and the product team must constantly evaluate the premises of their personas and update them if necessary. Also, personas may oversimplify user groups and product teams must be aware of this oversimplification. There is a need to add human diversity back into the design process and find mismatches in the product as Kat Holmes explains in Mismatch.