A persona is a way to illustrate the key audiences your work will impact. Personas can take on many different forms, but typically they are one-page documents that outline who your persona is, including demographic information and details about their life and context. 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.
Most teams use a few different personas to provide details about key audiences. These different personas help teams and stakeholders empathize with users and keep the correct users in mind when creating products and campaigns.
There’s a lot of debate around personas in design and research communities. 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.
The first question you need to ask yourself and your team is whether or not you have time to maintain your personas. Personas require research, both quantitative and qualitative, to get right. After the initial research, your team will need to maintain and update your personas regularly in order for them to remain effective.
Next, consider what you’ll do once you have your personas in hand. Will your design team use them to come up with new ideas? Will your stakeholders refer to them when evaluating the validity of a new product? Will the marketing team use them to create new campaigns? Thinking about what your personas will help you achieve at the outset can help you create personas that are more useful to your team.
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 your right now. Some teams find other methods to be more helpful, like the Jobs to Be Done framework. Many use both for different things.
There are many different schools of thought on personas. Some have created types of personas, which are helpful for learning more about the history of personas and their different goals. They are also helpful as jumping-off points if you’re stuck thinking about how your team can use personas. They aren’t, however, very helpful when attempting to build your own personas, so we’ve broken it down into some of the key elements of personas, and outlined how they can help you build personas that work for your team. You may not need every element, or need to complete every available part of every element, but there are a few must-haves. We’ve added a little ✅ to help you find them.
A quick note about demographics and naming your personas: Try to stay away from cheesy names like “Sassy Stacy” and “Marketing Manny.” This is a good way to turn people off to the seriousness of your personas, and creates an empathy barrier that makes it hard to see your personas as representations of real people. As for demographic information, think about every piece that goes into your persona. Do you really need to know their salary, exact age, or hair color? Maybe, but for most use cases, it’s likely that these things aren’t actually adding to your understanding of the persona. Ditch any unnecessary information and spend more time focusing on the parts of your persona that help paint a better picture.
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 in to 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 judgement 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.
Once you’ve decided that personas are the right tool for you and your team, the next step is to start building them. You’ll need to gather your team, chat about what you already know and assume about your users, decide how you want to use your personas, do some research, and sit down and actually create your personas.
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 personas.
First things first, you’ll need to take some time to sit down with your team and think long and hard about why you need personas and what you hope to learn from them. Think about 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 that 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.
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 in to 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.
Now it’s time for the fun part, talking to people. Your user interviews are a key part of building your personas, because it’s when you actually get to see the more human aspect of it all. 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 these interviews, take a moment to sit down and establish who your personas are. Once you’ve established patterns or clusters of users that define your personas, 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.
Need a little help thinking of questions to ask during your user interviews? Check out our chapter all about generative interviews, or read up on how to write great interview questions. When putting together your interview script, 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 in to the details.
Determining which of your personas make up which % of your overall user base and what their lifetime value is 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. 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.
After spending all this time and effort on your personas, make sure they’re as effective as possible.
This is one of the biggest reasons personas fail. Just like our products and services, users can change and evolve over time. Using personas that are outdated can lead you down paths that don’t actually help you build a better product.
Be sure you keep a good update cadence to get the most out of your personas. What does that mean? Well, it depends. If your product or market is evolving slowly, every year or two may be a fine update schedule. If your product or maket is moving at a faster pace, consider scaling it up with your research and development efforts, potentially to every half or every quarter.
NNg 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. Lastly, make your tweaks and distribute your updated personas to your team.
Ensure that your personas 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).
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.