7 Persona Mistakes

Many UX, Design, and Marketing professionals create and/or use personas. Personas have become so common that some would say that they are over-used.

Should we let go of personas? Should we stop using them?

One of the reasons that personas may be looked down on these days in some design circles is because people are making mistakes in how they create or use them. Below I’ve outlined some of the common mistakes I see around personas when I’m called in for consulting on a client project. And after discussing the mistakes, I offer a suggestion for an alternate tool in your Target Audience Toolbox. First, the mistakes:

1. Irrelevant information — a persona should only contain information that is relevant and useful to how the persona is going to be used. If you are creating a persona for Zoe, a potential customer opening up a bank account, then it’s probably not important to include how many cats Zoe owns. Don’t conflate trying to make Zoe realistic with what you really need to know and remember about Zoe.
2. Information that belongs elsewhere —  One of the most important tools to use during design are scenarios — quick small stories of how your target audience will do the most important and/or frequent tasks when your new service or product is available for them to use. Scenarios are so important, that they need to be on their own. Don’t try to include scenarios in your personas. It makes the persona too complicated, and doesn’t do justice to the scenarios.
3. Too many personas — If you feel you must segment  your target audience into 7 different slots (and I may argue with you about that need), that doesn’t mean you have to create 7 scenarios. You can’t optimize your product or service for 7 different personas at the same time, so don’t even try. Pick the most important 2 or at most 3 and create personas for them. Which brings us to the next mistake…
4. Using standard “Enterprise” personas — There’s nothing inherently wrong with creating lots of personas that different projects and teams can peruse and pull from to create their project personas as needed. But don’t forget the important step of reviewing and customizing persona before you use it. Enterprise personas should be a starting point. Some aspects of the personas may have changed over time, or not be exactly the same as what is needed for your project.
5. Not validating personas — There are two basic ways to create personas: a) interview a representative set of real people in your target audience, analyze the data, and then create personas or b) create a persona based from internal data and interviews with internal staff, and then go interview real people to validate the persona. If you do b) you can’t skip the validation step. If you skip it you are essentially creating your product or service for pretend people that might not be like your real target audience.
6. Creating your personas because it seems to be Step X in your process — Don’t create personas just because it’s listed as a “must do” in your process document. Decide ahead of time why you are creating them and who will use them.
7. Personas that are basically the same –
   How do you decide whether or not persona A is different enough from persona B that you actually need two different personas?  You look at the critical variables that you have decided on and see if they vary.

Which leads us to the tool you need to have BEFORE  you create personas, and might be the tool you use INSTEAD of personas…

When I teach about user research there is a step before I teach personas and that is identifying user groups. A persona is a fictional representation of a user group.

Let’s say that you are designing a banking app. Who is the target audience? You decide that you have three different target audiences. One is people who are already customers of your bank and are used to banking online. Another is people who are already customers of your bank, but are not used to banking online, and the third group is people who are not current customers, but are used to banking online, perhaps with one of your competitors.

The next question to ask is how these groups differ. What are the important criteria that distinguishes one from another? Is it whether or not they are current customers? Is it their familiarity with online banking? Is it something else? Where they live? What their native language is? How old they are? Based on the research you have (hopefully) done, you determine which variables are the important ones that distinguish one group from another.

Let’s say that when you look at your information you decide that whether or not they are a current customer won’t make any difference. That two of the user groups vary only on that one criteria, and your research tells  you that criteria is not that big a deal in terms of using your new app. In that case you can combine those two user groups into one.

A persona then is just a representative fictional person that summarizes one user group. And the persona would summarize them only on the variables that you think are important (i.e., no cats in this case).

But this also means that maybe you don’t need a persona. Here’s a secret — after creating a lot of personas throughout my career I’m going to confess that I don’t use them when I’m designing. I’ve created the user groups first and that’s what I work off of. I only create personas if a) the client asks me for them or b) we need to share this information out to others, such as stakeholders, developers, and so on. In my experience personas are more approachable than “User Group Tables” to people who are not used to them.

In summary, go ahead and use personas, but try and avoid making these mistakes. And if the  personas are just for you, consider using the prequel — the User Group Table — instead.

(If you are interested in learning more you may want to check out our User Research online video course, or our entire UX Certificate Curriculum.)