Note to the reader:
This part of the field guide comes from our 2019 version of the UX Research Field Guide. Updated content for this chapter is coming soon!
Want to know when it's released?
Subscribe to our newsletter!
Most people get personas wrong.
They’re useless, say some. Stop using them, say others.
The reality is, personas can be incredibly useful tools, promoting empathy, alignment, and direction for UX teams—but you have to do them right, and you have to do them well.
In this chapter, we’ll address the misuse and misconception of UX personas and set the record straight.
You’ll learn:
User personas are research-based, archetypal representations of your ideal customer. Personas can take on many different forms, but typically they are one-page documents that outline the context, motivations, and needs of specific user audiences.
Personas can be used by people in many different disciplines, including marketing, design, product management, and user research. Because they are such flexible tools, different departments within an organization may have different sets of personas, or may create personas that look entirely different from each other.
Whether you have one persona or many, personas are important because they help teams and stakeholders empathize with users and keep the correct audiences in mind when creating products and campaigns.
Because personas are used broadly, across disciplines, and for a variety of reasons, let’s clarify:
One of the biggest misconceptions people have about user personas is that they’re interchangeable with marketing personas. They’re not.
Yes, design teams and marketing teams both commonly use personas—but the persona documents they create are not interchangeable. If you get them mixed up, you won’t get (much) value out of them.
As Andy Budd, Co-Founder of Clearleft, says on the Awkward Silences podcast:
“I think personas for some reason get a really bad reputation. And I think the reason they get a really bad reputation is because people don't actually understand how they work. Generally, in my experience, a lot of people that are arguing against personas, first off, mix up design personas with marketing personas and that's really common.”
So, just to clear things up:
If the mix-up between design personas and marketing personas wasn’t enough, people also commonly confuse personas with empathy maps, customer journey maps, jobs to be done, and other mental models.
All of them represent some aspect of the user or customer audience, and all of them are used to help guide product and design teams when making decisions. However, there are some slight differences in the kind of information they contact and what they’re used for.
As Andy Budd says on the Awkward Silences podcast:
"Great design personas outline the context behind decision making, the approaches people may take to solve problems, and the scenarios they may find themselves in."
Under the umbrella of design personas, there are also different types of personas you can create. They include:
Although the amount and rigor of research varies, each persona type must be based on real data in order to be valuable. As Page Laubheimer of Nielsen Norman Group says:
“Personas used in UX work are a quick, empathy-inducing shorthand for our users’ context, motivations, needs, and approaches to using our products. They are meant to help us focus on what matters most to our users and put ourselves in their shoes when making design decisions. Because of this, they must always be rooted in a qualitative understanding of users and reflect the what and why that drives them. They should not be based on (often dubious) correlations between different demographic or analytics variables.”
There’s a lot of debate around personas in design and research communities. The question is: What’s the purpose of personas? And when do I need them?
When, where, and how you use personas depends heavily on your team’s situation and goals, so it’s important to understand your goals and how your team works before creating personas.
Deciding whether or not personas are right for your team requires you to consider:
Ultimately, if you can’t think of good, concrete ways in which having personas in hand will help your team, don’t create personas. Creating personas simply because it seems like the right thing to do, unfortunately, won’t be a good use of your time. Personas don’t work for every team or every context, so it’s very possible personas aren’t the right tool for you right now.
Below, we’ve listed some of the pros and cons of personas to help you weigh the value of them for your team.
Personas provide a number of benefits for UX teams. They help:
Humanizing research findings is a particular boon for UX researchers, a salve to the common pain of getting stakeholders to take interest in (and make use of) research reports. As Budd says on the Awkward Silences podcast:
“The first thing I think is worth understanding what the purpose of a design persona is. And I think the primary purpose for me is breathing life into what is often quite large amounts of complicated research data.”
As with any research deliverable, personas come with their own challenges and drawbacks. The main cons of personas include:
However, small-sample research can be built upon in future studies for improved accuracy and breadth. And even research teams of one might find them to be a worthwhile project, depending on the needs and goals of their business.
Understanding why and how personas fail can help you determine whether or not they’re worth it for your team—and avoid problems if/when you create them in the future.
As Kim Salazar of Nielsen Norman Group explains, the most common pitfalls of personas include:
However, many of these pitfalls can be avoided with proper research evangelism, stakeholder alignment, and actually-good research. Experienced UX researchers with a strong Research Ops strategy (whether managed by themselves or with a dedicated ReOps function) should be able to easily overcome them to make good use of personas.
If you’ve decided that personas are the right way to go, here are some tips on how to create user personas that are actually useful for UX teams.
Since our Field Guide is all about user research, we’ll focus on creating personas for design and product teams. If you’re using your personas primarily for marketing, check out Hubspot’s guide to buyer marketing personas.
First things first, you’ll need to take some time to sit down with your team and think about:
Discuss what you already know about your users, from previous research, product data, or a gut feeling you and others have developed over time. Together, come up with a hypothesis (or a few hypotheses) about what your user segments, and eventually your personas, may look like. In this stage you’re looking for clusters of users who behave in similar ways.
Also consider what you’re trying to do with this persona—is it to develop a new product, create new features, or to design a better experience? This will help you find good jumping off points for the next two steps.
In the design-thinking process of product design, personas are built during the “define” phase—before you begin ideating solutions or creating prototypes. Although it’s helpful to build personas early on, you’ll also need to evolve them as you learn more and mature as an organization.
It’s important to come out of this phase with a hypothesis. This means you’re not going into your data-collection and research phases trying to validate an idea, you’re going into them to try to learn. It’s possible, even probable, that your hypotheses will be wrong and you’ll end up with a persona that looks quite different from what you originally imagined. That’s ok. That’s why you’re doing this in the first place.
To determine your audience’s core persona types, you have to ask the right questions.
Check out our chapter all about generative interviews, or read up on how to write great interview questions. Usability.gov also provides great examples of questions to ask during persona development here.
When putting together your persona interview questions, try to ask open-ended questions that ask the participant to remember a specific experience. People are pretty bad at self-assessment, which means if you simply ask them exactly what you want to know, you may not get an answer that gives you good insight.
Instead, ask open-ended questions like, “Walk me through the last time you used our product.” Questions like this allow you to make observations about their process, and ask follow-up questions that help you dig into the details.
Now it’s time for the fun part: talking to people.
User interviews are a key part of building your personas, because it’s when you actually get to see the more human aspect of your users.
It’s best to start off talking to 5-10 people who represent your user base at large, to make sure that your hypotheses are on the right track.
After you complete your initial interviews, take a moment to sit down and identify patterns or clusters of users that could define your personas.
When you’ve started mapping out skeleton personas based on this initial data, you might want to interview a few more people that fall into that persona. This can help you build out your personas even more and ensure you’re on the right track. These interviews will give you an opportunity to get into the real goal of building personas—writing a story that helps your team connect with your users, keep their needs in mind, and prioritize which users need which things.
As you’re evaluating your data, keep an open mind—you might be surprised by what the data reveals about who your actual customers are.
The next step is to make use of any data you already have. This can be analytics, sales and support data, or user feedback surveys.
Use this data to determine:
This can help you decide which personas to prioritize, and which ones aren’t actually doing well for your business. This data can also help bring more detail to your final personas, beyond what you learned in your interviews.
Time to make some personas 🎉!
Your personas will help tell the story of your users, and will help your team empathize with them every step of the way. So it’s important to spend some quality time creating your personas. Try to build out their stories to make it easier to remember them next time a project comes up.
💡Pro tips for creating effective user personas include:
We’ve created a template to help you build out the basics of your personas, but have left it pretty bare-bones to leave room for imagination. Feel free to start with our template, but build something that represents your personas in a way that’s digestible and accessible for your team.
You can also get creative with other assets to help reinforce your personas with your team, like these cool persona posters, or these persona trading cards. It’s important to note that assets like this are secondary to your persona documents, which should be more detailed.
These are the goals the users represented by your persona are trying to achieve. Goals are pretty integral to your persona, in fact, goal-driven personas were the very first personas. They were thought up by Alan Cooper as a way to empathize and analyze the users he was designing for.
These user goals should be user-centric, not product-centric. Since no one logs on to an app and says to themselves “I want to complete this flow successfully,” it’s important to think about what the user’s actual goals are when they come to your site or product. Do they need to buy a new hat? Why? You can use frameworks like the 5 whys to uncover these goals through user interviews. Try to get to their root motivations for taking action, as these will help you consider how this persona might act in different situations.
Different people approach problems with different skill sets, and your personas should too. For example, some users may be less tech-savvy than others, or less familiar with your product. Taking note of this can help you build something that takes their skills into account.
This section can also be used to help build out the character of your persona. Adding skills like creativity, empathy, or self-sufficiency can help paint a better picture of who your persona represents and how they may approach a new problem. Keep your list of skills concise to avoid overloading your persona and making them seem less realistic.
Attitudes dig into the existing attitudes your users may have when they approach your product. Attitudes can help you learn more about how a persona would approach a new situation, and are best illustrated in short statements. If you’ve found some particularly illustrative quotes through your research, this may be a good place to add them in. Your personas attitudes will also illustrate more of their life outside of your product. For example:
Loren is pretty self-sufficient. She knows how to get things done on her own, but doesn’t get too worked up if something doesn’t go her way. She believes that life is what you make it and will step back to try to find a different solution rather than continuing on with something that doesn’t work.
Where do these users typically run into problems? What does their journey look like, and why do they need the thing that you’re building? These pain points are things you can potentially help your users with, and at the very least, they can help you understand your users more deeply.
Think about how these pain points may present themselves to your users, and consider writing a small paragraph about your persona’s pain points to help put them in context. For example:
John is a high school student, he’s excited to go to college but is struggling to choose a school. He feels overwhelmed by the number of choices available to him, and does not know how to sort through them all. Between academics and extracurriculars, he does not have enough time to research schools.
Writing out pain points in context like this helps your team to empathize with John, and think of good solutions to help solve his problems. Maybe some sort of college recommendation engine? Or a searchable sorting tool?
Environmental factors help build the world around your personas. Since people don’t act in a vacuum, it’s important to understand what goes on around them. This is an element of your personas that will vary widely from team to team. You may need some of these environmental factors, but it’s unlikely you’ll need them all.
For example, if you’re building a sales pipeline tool, it may not be important to include that the user has two cats. Likewise, if you’re building an app to share photos of cats, it may not be important to include that your user has a deadline-driven job. Use your best judgment when deciding what to include and do your best to keep it to the necessities, adding just enough color to make your persona feel real without going overboard.
You may need to know things about your user’s personal lives. This could range from their relationships to how often they order in, depending on your product and what you’re building.
As with every part of your persona, be sure to describe this part of your persona in a way that is illustrative and engaging.
What does your user do for work? Who do they work with? Are they passionate about their job? Questions like these will help you build out your persona’s professional life. This is especially important if you’re building a tool for their work life.
For example, if you work for a B2B SaaS tool, what your persona does for a living is incredibly important. Their budget, the way they work with their team, and the way their boss thinks about their performance (and thus, their budget), will have a big effect on whether or not they end up using your product, and may be important to include in your persona descriptions.
This is potentially the most integral part of your persona’s environmental factors. Their workflows or journeys are what happens around the use of your product.
For the cat photo-sharing app, where do they take pictures of their cat? Are they avid users of other social media? Are they sharing cat photos to build community or simply to let everyone know their cat is the cutest?
For the B2B SaaS app, how does your product help them do their job? Do other members of their team need to use the product too? Do they use other tools before or after yours to complete the job?
Questions like these will help you build out potential workflows or journeys for your personas, making them more useful for your design and product teams.
Many teams will end up with 3–5 personas. (Try to cap it at 5—any more than that will usually become cumbersome, unless you truly have that many unique user segments that warrant a persona).
By looking at your analytics data in step 5, you should’ve been able to figure out which personas make up which percentage of your overall user base, and what each persona’s lifetime value is. Use this information to rank and prioritize your personas based on which groups are likely to provide the most value for your time. You might include:
Personas (just like the real people they’re based on) evolve. You need to revisit and update them periodically to keep up with those evolutions.
As Matt Brown of Nielsen Norman Group says:
“We sometimes think of personas as final artifacts, when, in reality, personas are merely a representation of data, and data can change. An artifact that is too polished or difficult to update may result in an outdated and unused persona.”
However, don’t update personas just for the sake of it. It’s best to update them when you’ve experienced changes in:
NN/g ran a survey to determine how often most people update their personas and how effective those personas were. Most of their respondents updated their personas once every 1-4 years, but the 28% of people who updated their personas quarterly or more often consistently rated their personas highly impactful.
Updating your personas doesn’t have to be a chore. Take a look at the data that you’re using in your current personas, and check to see if there’s any new data you can make use of. This data can include things like lifetime spend, % of overall users, NPS scores, or churn rate. If you’re seeing a lot of discrepancies in your data and any other research you may have conducted, do a few (3-5) generative interviews to learn more about how your personas are doing well and how they can be improved.
Distribute your personas to your team and ensure that they’re a part of every product and design decision you make.
Creating secondary persona assets (like those posters and cards) can help your team think about your personas more often. It’s even more helpful, though, to integrate your personas into your existing workflows, establishing them as an important part of the process.
Consider attaching a relevant persona to each of your team’s projects. Who are you building this thing for? How will they use it? Asking these questions will help you choose the right persona and prioritize projects more effectively.
Elizabeth Bacon and Steve Cooper have some good tips on integrating your personas into your workflow in their slidedeck all about personas (skip to slide 56 for their tips).
Luckily, user personas are a common, structured research deliverable, so there are plenty of templates and examples to explore. Here’s a few of our favorites ⬇️
Typically, personas are presented visually in slides, infographics, or PDFs. Popular tools for creating persona deliverables like these include:
If, for whatever reason, none of these tools are available to you, a good ol’ Google Doc would suffice.
Personas can be a great tool for your design and product workflows, but only if you use them carefully and correctly. Like any other research tool, they require a bit of care and attention to get right. Once you have them, though, they can help your design and product teams think more actively about your users and incorporate them into the decision making process.