How to: Write personas that work
An integral part of the UX process, personas are the main tool helping keep users and their goals in mind. When done well, they can provide a solid backing for product development, enhance participant selection for testing, and ensure team agreement on motivations and pain points. When personas don’t work, they can hold up these processes.
So how can you ensure that the personas you build set your team up for success? It starts with getting the basics right.
What are personas?
Personas are tools used to represent a particular type of user of a product or service. Their purpose is ultimately to allow project teams and stakeholders to define the target audience in a way that actively contributes to the development of the product. Personas are used throughout the UX process to ensure that the outcome is solving a user's problem or helping them meet their goal. Overall, they help project teams keep the user in mind and maintain a common understanding of who the users are and what they want.
What makes a persona useful?
Personas can be helpful in all stages of the UX process right from the defining stages to the final stages of testing and iteration helping determine who to test with and what’s still missing. So what makes a persona useful to this process and how can you start writing personas that add value to your projects?
The three types of personas
Personas commonly come in three forms that rely on varying amounts of data and research but generally serve a similar purpose in product development. Which type of persona you build will depend on the data and research budget available for the project.
1. Proto Personas
Proto personas are written to align the team’s existing assumptions about who users are fast based on existing research and data.
2. Qualitative Personas
Qualitative personas are based on small-sample data like that collected through interviews or usability tests.
3. Statistical Personas
Statistical personas are based on large data sets often collected via survey.
Whichever type of persona you are building, the basic components and considerations are generally the same. To determine if a persona is going to be valuable to the project, you can start with these basics and if needed add other data that is relevant to the product or domain.
Start with the basics
Whether you’re designing a website or building a brand, personas all serve the same general purpose: to ensure everyone is on the same page about who the users are and what they need. All useful personas include the following attributes:
- A face/image of the persona
- A name, demographic info, and a bio
- Goals and motivations
- Challenges or pain points
- Other user information relevant to the product or service
Let’s break down how each of these elements contributes to the persona…
1. The face behind the user
As human beings, our first impression of someone often comes visually when we look into their eyes building an instant connection. We relate to them, we empathize, we search their face for emotions, and we use their face to help our brains remember who they are.
The same is true when we see a picture of someone we don’t know, like a persona. We use a face to help us remember who someone is and empathize with them. That’s why using a big, clear image of the persona's face is so important to the UX process. It’s the start of seeing the product through the user's eyes by understanding their pain points and goals and connecting this to a persona representative of a user group.
Note: Ensuring that the personas you work with represent a diverse cross section of users starts with the face. Choose faces of users reflecting different cultural backgrounds, genders, body types, and ages to ensure diversity is at the heart of the project.
2. What’s in a name…
Persona names should be simple so the team can not only remember them, and not dwell on how to pronounce them. Names are useful to help the team make a mental connection between the persona and their needs and be able to talk about this user with other team members easily.
For example, if Jack is a persona for Bank A, the whole team will know that Jack is a busy millennial dad looking for an easier way to pay his bills and send e-transfers on the app when his hands are full.
Without a name, Jack would seem like (a) an abstract entity rather than a real person, and (b) a complex set of goals that need to be recounted and described to the group each time he is brought up.
Similarly, when building a persona, each should be represented as an actual person. Giving the persona an age, occupation, location, and other basic demographic data helps enhance their reality. Including a short bio helps cement this impression by giving them a comprehensive story of who they are and why or how they use the product.
3. What do they want and why?
Beyond who the persona is, we need to know what they want and why– not in an existential sense, but rather as a user of your product or service. These goals should not be prescriptively specific or focus on a certain feature, rather, they should provide a high-level overview of what the user wants from the product as a whole.
Goals are the objectives of the persona and can describe their emotional or experiential desire for the product [experience goals], what the user wants to accomplish [end goals], or what they want in a broader sense [life goal]. Motivations are the driving reasons behind these goals and can be visceral feelings, reflective desires for who they want to be, or behavioral impressions of what they want to do.
For example, Jack (our busy millennial dad) wants to reduce the amount of time it takes to send an e-transfer [experience goal] because he wants to spend more time with his kids [behavioral motivation]. He also wants to pay his bills on his phone [end goal] because convenience [viceral motivation] is important to him.
We can use these goals to define user stories, direct research into features, and determine how the product can meet the needs of users like Jack who value convenience.
4. What makes them tick?
Pain points are the things that make each persona tick. Similar to goals, these pain points are the high-level challenges or pet peeves that define what we need to fix or avoid in the product to keep this particular type of user happy.
Pain points can be any problem or negative emotion users experience at any point in their journey with the product. Just like goals, they can be related to the experience, an end goal, or a broader life issue or hatred.
For example, Jack may be annoyed by all of the notifications he receives from his bank since they interrupt his day, he may also have a general hatred of paper statements since they’re easily lost in his busy household and he’s environmentally conscious.
5. What else actually matters?
If you’ve included everything up to this point, your persona is ready to go. Congratulations! 🎉
However, depending on the product or service your persona is written for, there may be some additional elements that can bring the whole thing together in a complete package making your persona into a real user….
Other data to include in personas
Character tropes
The character trope allows us to understand the persona’s personality traits before reading through making it a good way to introduce the user to a large group of stakeholders or researchers and ensure everyone holds a similar objective understanding of what the persona is like. There are many possible ways to go about archetypes including:
- Myers-Briggs personality type, i.e., The Architect, The Advocate
- A fun alliterative coupling, i.e., Creative Christine, Work-a-holic Wendal
- The classic narrative archetypes, i.e., The Explorer, The Rebel
For example, Jack is ‘ The Authentic’ meaning he tends not to seek external validation and tells the truth sometimes to a fault.
Preferences
Are you defining the users of an e-commerce brand? Why not include their favorite items to use or purchase. For a software product, how about the other software platforms they use regularly? For an outdoors brand, what are their favorite activities or campsites?
These preferences can help define what a user likes and enhance the persona by creating a deeper story about their life. Be sure to portray a variety of preferences across the different personas used in the project to ensure that the team won’t hyper focus on one product area over all others.
For example, Jack prefers using the ATM at his local bank branch to seeing a teller but Carol exclusively does her banking in person and hates ATM machines. Considering both of their preferences can ensure the team caters to a variety of users.
Quotes
Why not quote the persona directly by using their own (fictional) words to restate their ultimate goals or priorities. This quote can help set up a narrative for the user and quickly summarize what they want in a sentence or two.
Key scenarios
Including a few key micro-scenarios in a persona can be a great way to expand on their individual use cases. These key scenarios should be shorter than your typical scenario, only a sentence long, and be a direct extension of the user's goals.
Proficiencies
Using sliders or charts can be useful to show the persona's proficiency or use of certain parts of the product, or comprehension of technology.
Consider what is important to know about your persona’s interaction with the product. Do they rely on the help center often? Are they an avid online shopper familiar with one-click checkouts? Or, do they only have access to public internet networks?
What to avoid in a persona
Don’t focus on irrelevant data
Avoid focusing too much on life goals and personality quirks at the expense of real useful information related to the product or domain. It’s less important to know how important Jack’s kids are to him if his goal is to spend less time sending e-transfers.
Similarly, knowing a personas full family history, how many times they’ve been divorced, where their parents emigrated from, or their sexual orientation are often irrelevant to the product’s development since they narrow in on an overly specific idea of the user. Unless the broad data statistically reflects these points AND they hold relevance to the product or domain, just leave them out.
Personality sliders may look good but rarely matter
One of the most popular additions to UX personas is a section dedicated to personality sliders representing traits like introversion and extroversion, thinking versus feeling (essentially a reproduced Myers-Briggs indicator). Here’s the main issue with including this data: Why does it matter?
While archetypes provide an implication of personality, these sliders are an overtly specific and irrelevant factoid that holds virtually no sway on the development of the product. How does knowing that Jack is 54% extroverted and 68% perceiving affect how we develop our banking app? Unless you can defend the relevance of the data, just leave it out.
Don’t just write personas, build them
Personas are a defining part of the UX process that most beginners are eager to jump into headfirst, longing to design their ideal user like a Sims character who eats, sleeps, and breaths the product.
But building personas that work takes time, research, and a comprehensive understanding of the aspects of a persona that genuinely contribute to the strategic definition of the product or service. Designing personas should be done with care, building them from data and insights that genuinely benefit the product team in their mission.
