How to Get the Most Out of User Personas
Personas can be helpful research tools, but they’re not perfect. In this post, we’ll explore where personas shine, why they sometimes fail, and ways to use them effectively without blowing your budget.
If you’re creating a new product, you want to be sure it solves the right problems for the right people. By focusing on the problems of specific customer types, you’ll have a far higher chance of creating something they will actually enjoy using. Personas can keep your product development efforts focused on customer needs, but they can also lead to problems.
A Party of Personas
Personas are fictionalized characterizations meant to help marketing, design, and product teams better empathize with a target customer or user’s desires, goals, behaviors, or limitations in relation to how they might interact with your product or service. They typically include generalized customer traits, such as demographic information, pain points, values, goals, personal preferences, employment, potential objections, and so on. They also serve as alignment tools for product stakeholders to build consensus on who they are trying to reach and what is most important to those people. These can contribute to sustainable web design practices by allowing organizations to better tailor their digital products to their users. Persona exercises can also be useful tools when running discovery workshops or in user research and testing.
Personas typically come in two primary flavors, which are often confused:
Marketing personas, also called buyer profiles or customer personas, tend to focus on buyer habits, distribution channels, and demographics. They exist to identify market segments and specific buyers within those segments and may include a customer’s ability to purchase a specific product or details about their personal life as related to how they interact with your product or company.
If marketing personas define who your customer is, then user personas define how they engage with your brand online. For digital projects, user personas focus on creating empathy for users. Demographic information, for instance, might be less useful unless it is directly relevant to decisions made by design teams to foster better usability. The focus instead is usually on studying people’s behavioral patterns. Design leader Alan Cooper is credited with creating the standard user persona back in the 80s.
We have employed user personas on projects at Mightybytes with varying degrees of success. Some we have workshopped with clients, others we created independently based on research. A few may have included more demographic information than necessary for generating user (as opposed to buyer) empathy. Yet all were devised in the service of helping both our clients and production teams better understand the people we wanted to reach.
The Problem with Personas
Personas have received criticism for numerous reasons, the most common being:
- Because they are fictional and created at the outset of a product’s development cycle, there may not be a clear relationship between aspirational traits outlined in personas and what real users actually want.
- They are often created by third parties as part of extensive and costly studies, so teams might hesitate to question their assumptions.
- They can be used to justify poor product decisions that actually distance the very customers they espouse to personify.
In their O’Reilly Media book Lean UX: Designing Great Products with Agile Teams, authors Jeff Gothelf and Josh Seiden note that the traditional method of creating detailed personas based on extensive upfront research is flawed:
Most of us learned to think about personas as a tool to represent what we learned in our research. And it was often the case that we created personas as the output of lengthy, expensive research studies. There are a few problems with personas that are created this way. First, we tend to regard them as untouchable because of all of the work that went into creating them. In addition, it’s often the case that these personas were created by a research team or third-party vendor. This creates a risky knowledge gap between the people who conducted the research and those who are using the personas.
Author and user researcher Steve Portigal also notes in his white paper Persona Non Grata that personas are easy to misuse because of how they actually depersonalize the real people they are meant to embrace.
Personas are misused to maintain a “safe” distance from the people we design for, manifesting contempt over understanding, and creating the facade of user-centeredness while merely reinforcing who we want to be designing for and selling to.
In his paper, Steve describes how a client described various persona types in “infantilizing” ways, i.e. Critical Incident Carl or Integrator Ian. Steve also notes that the “ease with which she spoke to us about real people as if they were characters from the Strawberry Shortcake universe was distressing.” Which is just an awesome way to describe this disconnect.
It is easy to see in these examples how inefficient traditional personas are at helping product stakeholders think about potential customers as real people. They enable teams to justify creating features based on aspirational caricatures and manufactured details without validating whether actual humans care about those features and want to use them. That said, is it viable to use personas when creating digital products and services? Yes, but we should rethink them a bit.
Going Lean with Proto-Personas
Proto-personas, also known as lean personas, are based on hunches rather than hard research and serve several purposes:
- They jump-start the research process by quickly building consensus as part of a workshop.
- They can also help you quickly align business goals with those user needs.
- They foster important discussions with project stakeholders throughout the entire product development life cycle.
Lean personas have two important distinctions from their more traditional counterparts:
- They are created after you make assumptions about what users want, not before.
- The learning process is ongoing for lean personas.
Let’s explore what we mean by that in a bit more detail.
Assumptions Before Personas
Researchers can spend weeks or even months in the field collecting data for traditional personas. Proto-personas, in contrast, can be completed during a short workshop session. You start with a team’s understanding of project requirements and users first, then move on to research in order to validate assumptions. With more traditional methods, it’s the other way around. As such, proto-personas can be helpful when you need to do UX on a budget.
Proto-Personas and Continuous Learning
Using Lean UX tactics, such as ongoing testing and prototyping, product teams will validate or refute assumptions made about customers and re-prioritize based on what they learned from those tactics. The personas are then adjusted accordingly over time so they always reflect the latest insights learned as the product takes shape. This helps stakeholders maintain consensus and better target customer needs as the product or service continues to evolve.
Running a Lean Persona Workshop
Let’s look at how this plays out in the real world. First, get your key stakeholders—product managers, marketers, UX designers, content strategists, clients, etc.—in a room. For this exercise, you will focus on just a single user type. You can repeat the process as many times as necessary, but the point is to collect enough information to build consensus within the group about that user type. This will form the basis for further discussions about desired outcomes and, eventually, a hypothesis about the features you might build to meet their needs, which you will eventually validate with further testing and research.
Give everyone a template (see below) and have them fill out the persona sheet to the best their knowledge about a specific user:
- Goals: Why are they using your product or service?
- Tasks: How are they interacting with it?
- Feelings: What is on their mind before and during use?
- Influences: What is going on behind the scenes?
- Pain Points: What obstacles keep them from achieving their goals?
Limit your participants’ time to around 10 minutes for filling out the template. This time constraint will help you capture gut reactions based on instincts and minimize participants overthinking the exercise. Additional details that confirm or refute your initial understanding will come with more extensive research later.
Once everyone has completed filling out their template, have each person present their persona, and open up the conversation to the rest of the group. What points were missed, what solutions does the persona inspire? Where are there differences of opinion in your group? Explore those and collect any key insights during the discussion. If applicable, prioritize or highlight key insights from each persona for reference later (see colored dots in the image above). Spend about 30 minutes presenting and discussing the personas with workshop participants.
Dovetailing Personas with Content Strategy
Depending on the nature of your project, a proto-persona workshop could also occur alongside a content strategy matrix exercise that compares your company’s business and marketing goals with user goals to find common ground. Using your completed matrix, rank the personas that best match those common goals. These are the personas to prioritize during the design process.
A proto-persona workshop is meant to help key product stakeholders collaborate quickly to get primary insights, and then fill in gaps later with more time-consuming research efforts, rather than the other way around. By starting with quantitative online research tools and removing the human element, it can be easy to get lost in the data and spend more time researching personas upfront than might be useful for your project.
Are Proto-Personas the Answer?
Proto-personas won’t be the silver bullet for every website or digital product. They can, however, jump start important conversations that enable your team to quickly validate or refute assumptions about user needs. They also lay the groundwork for critical discussions about desired project outcomes and feature hypotheses that you can test with real users as your product or service begins to take shape.
The key to their success is to use them as a resource throughout your product’s life cycle rather than setting them aside as you continue the design process. Update them as you engage in new customer conversations or conduct usability studies. Every piece of new information should continue to inform your team’s beliefs about target users and their needs so you can design for multiple audiences. By taking this approach you can be assured that future efforts will more succinctly hit their mark.