User personas are controversial. They’re built with great intentions, and then break down. People aren’t sure how to create them. They sit in drawers and hang on the wall, forgotten or ignored. But personas can be very beneficial they’re created and used properly. if Here are a few reasons why your personas may be failing and some fixes to turn them into a useful resource. What’s the problem with personas? The issue isn’t with the tool itself, it’s the fact that they have been misunderstood and misused over the years. Product teams have gotten tired of the bad experiences that come with this. The main cause of the problems is that personas get mixed up with personas. Sales departments were using personas long before we were, and the two types got jumbled together. design marketing But the two don’t mix — they serve different purposes. Marketing focuses on info that isn’t useful for designers or is downright distracting. Product people don’t just want to know the , we want to know the . what why Take this example: Jill is a Wisconsin soccer mom with three kids in an upper-middle-class income bracket who is the PTA president. That persona might help the sales team know how to target Jill, but it doesn’t help the design team make a good product for her. We need to untangle marketing persona practices from UX personas, and help product teams use them correctly. Best practices Here are a few principles that will help you steer your personas in the right direction. Discover from research Too often, personas are based on whims and guesses instead of (I’m looking at you, proto-personas). research Actionable, accurate, useful personas are , not . They are a result of research. They’re a data visualization. You don’t begin with personas, you gather and analyze research to see where personas emerge. discovered created If we don’t have the data, we don’t make a persona. We can use something else to capture assumptions, like an . assumption map Add only relevant, useful information Personas should be short, digestible, and focused. Every piece of information should have a purpose for being included. Only add data that directly affects the design process. Lots of persona templates or examples have things like personality spectrums, favorite music, hobbies, and so on. These charts might look nice, but they’re usually unclear or irrelevant. A designer can’t get anything actionable from knowing that a persona got a 4 out of 5 on “Open to new experiences.” Condense things down to avoid clutter and noise, and focus on data that matters. And remember you don’t have to rely on knowing someone’s favorite food to empathize with them (more on that later). What do I include? It always depends on your project. But try starting with these things: One or two major pains or needs. Key motivations, attitudes, and behaviors. Tech usage. Tasks, workflows, or . jobs-to-be-done A first-person narrative that describes the above to help you empathize more with them. Involve everyone in making them You may run into problems if you create your personas in a silo and then unveil them like a piece of artwork to be imposed on everybody. Instead, get others involved. Everyone who is going to the personas should be involved in them. This builds a feeling of ownership and approval. use making Invite teammates to sit in on research sessions. Get help brainstorming persona names. Keep the team updated on how the research is going and explain decisions. Figure out ways to get others involved until everyone is happy with the final product. "Personas work best when co-researched and co-created." — Jeff Gothelf Include psychographics, not demographics Demographics are a carryover from marketing personas. In UX, what we’re really after is psychographics: , motivations, pain points, attitudes, and behaviors. Statistics like age, gender, ethnicity, and location do not cause thinking or behavior, so they have no bearing on the design process. mental models There is a in the UX field to completely leave out demographics from personas (unless your particular product is demographic-specific). rising movement all We want archetypes, not stereotypes No matter how well-made they are, personas that have demographic information can easily start to feel like tropes: the bro, the shopaholic, the fitness enthusiast, the Apple geek, etc. Once that happens, things go downhill. It’s hard to feel empathy for a cliché, and lots of them carry negative baggage. If you’re holding back an eye roll, you probably have a stereotype (not an archetype) on your hands. Demographics cause problems. Attributes like gender, age, and race trigger our brain to think in stereotypes and assumptions. It can even lead us to favor one persona over another. In the past, demographics have been used to make personas feel more relatable and help us empathize with them. But as says: Indi Young "To actually bring a description to life, to actually develop empathy, you need the deeper, underlying reasoning behind the preferences and statements-of-fact." Limit how many you own A product team should only have a handful of personas. Having too many takes away their ability to become memorable or useful. We can aim for a ballpark of 3 to 5. Having this low number requires that we use the right . Remember it’s better to paint with a broad brush and meet the needs of larger groups of users than try to account for every edge case. The goal of personas is to focus on the major needs of the largest and most important users. scope Use them properly Most people aren’t well educated on what personas are or how to use them, especially if they aren’t UX designers. So our job is to and . lead by example teach others Get a core group of advocates to help lead the charge. Teach people how to write user stories with personas in mind. Put them out where people can see them. Bring them up in design meetings and keep them in the narrative of your product. You want to get them off the paper and into the minds of your team so they come up organically. It’s also important to know the limits of personas and educate others on what those limits are. They’re useful, but they’re only in your tool belt. They don’t have all the answers, and they aren’t the right approach for every decision. one tool Update them over time Our personas should be living, breathing representations, not stagnant, stale PDFs. You don’t make it once and then lock it away forever behind a glass door. This means they need to change over time and adapt to the research we perform. When new data comes in, we should update our personas according to what we’ve learned. Don’t forget to proactively revisit and reprocess them every once in a while. It’s an ongoing project. What are the benefits of correctly-built personas? When you get personas right, they offer lots of benefits: , especially to others on the team who weren’t able to be part of the research process. Communicate research findings clearly and succinctly and a shared understanding and vocabulary about who you work for. Stay focused and avoid getting stuck in the weeds. Give your whole team a central point of reference Our brains are wired to empathize with . So using a collective noun (like saying, “the user”) prevents us from empathizing with our userbase. We can’t wrap our heads around a big group of people, but we instantly connect with one individual. When groups of users are represented by a persona, imagining what they would do is a lot easier than pouring over cold, hard, abstract data. Help you relate to and remember your users better. individuals, not groups When people start giving their assumptions and making guesses, you can go back to your research-backed persona to point out what really matters. Make better decisions. , like empathy maps, user scenarios, journey maps, user interviews, and . Augment other types of research user flows Wrapping up I’m curious to hear if this helped you better understand user personas. If you still have questions or want to talk through things, I’m always happy to chat . on Twitter For more articles like this, sign up for the Learn UXD newsletter: . https://learnuxd.io/newsletter Originally published on learnuxd.io.
