7 Persona Mistakes

Man in hood without face putting hand out to say stopMany 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.)

Mistakes People Make With Personas, And Why You Should Care

Logo for HumanTech podcastCreating personas before you design a product seems quaint and old-fashioned these days. In this Human Tech podcast episode we get UX-nerdy and talk about why we still think personas can be useful, how they help you design, and the mistakes that people make when they create personas.


Human Tech is a podcast at the intersection of humans, brain science, and technology. Your hosts Guthrie and Dr. Susan Weinschenk explore how behavioral and brain science affects our technologies and how technologies affect our brains.

You can subscribe to the HumanTech podcast through iTunes, Stitcher, or where ever you listen to podcasts.

How To Get People To Do Stuff: #1 — Use Nouns Instead Of Verbs

"I am a voter"This blog post is the first of a new series called “How To Get People To Do Stuff”. It features nuggets from the book I am writing by the same name due out in March of 2013.

I’m also starting a new format of doing video blogs. So first is the video, and then below it is the text that I talk about in the video.

Let me know what you think about the new topic series and whether you like the video format!

Here’s the research:

Walton, Gregory and Banaji, Mahzarin, Being what you say: the effect of essentialist linguistic labels on preferences, Social Cognition, Vol. 22, No. 2, 2004, pp. 193-213.

In a survey about voting, Gregory Walton at Stanford sometimes asked  “How important is it to you to be a voter in tomorrow’s election?” versus  “How important is it to you to vote in tomorrow’s election?”

The first sentence was phrased so that the emphasis was on the noun, “voter”. The second sentence emphasized “to vote”. Did the wording make a difference?

11% more voted — When the the noun (be a voter) was used instead of the verb (to vote), 11% more people actually voted the following day.  Why would nouns affect behavior more than verbs?

Needing to belong — I had always learned that using direct verbs resulted in more action. But if using a noun invokes group identity, that will trump a direct verb. People have a strong need to feel that they belong. People identify themselves in terms of the groups they belong to and this sense of group can deeply affect their behavior. You can stimulate group identity just by the way you have people talk about themselves or the way you phrase a question. For example, research shows that if people say “I am a chocolate eater” versus “I eat chocolate a lot” it will affect how strong their preference is for chocolate. “Eater” is a noun. “Eat” is a verb.

When you are trying to get people to do stuff try using nouns rather than verbs. Invoke a sense of belonging to a group and it is much more likely that people will comply with your request.

What do you think? Have you tried nouns instead of verbs?

4 Ways Personas & Scenarios Result In Great Design

 

Drawing of stick people connected by dotted lines

I find myself these days working on two streams: on the one hand I’m working on my next new project (which is another book called “How To Get People To Do Stuff”) and on the other hand I’m recording a series of online training videos that cover the basics of doing usable design. Sometimes I think we get all caught up in new stuff and new ideas (Pinterest! apps!) and forget about the great stuff we’ve all worked hard to figure out… like personas and scenarios!

Developing and documenting personas and scenarios as part of a design process is not new. It’s been around for at least 30 years, and maybe more. But I was recently reminded of how powerful they both are in ensuring you do great design.

So in case you have forgotten WHY using personas and scenarios on your project results in great design, or in case you never knew, or in case you know but sometimes have a hard time explaining it to others, you can use this blog post, and the short video that goes with it, to remind yourself and/or explain to others.

I took excerpts from my latest online video course, “How to Develop & Document Personas & Scenarios”. to make a short video on the 4 Ways Personas & Scenarios Result In Great Design:

 

Here’s a summary of the video.

4 Ways Personas & Scenarios Result in Great Design

 1. Bring assumptions into the open — When you do design there is always a moment (actually dozens or hundreds of moments) when you are deciding something. For example, should I put the button here? What should I call this? Should I separate this into 2 pages? Whether you are aware of it or not, at that moment you are making that decision, you have many assumptions operating about your audience, who they are, what they are trying to accomplish, etc. Some of those assumptions are based on your knowledge and facts, other assumptions are probably biased, as in, “I think this would be best” (implying your audience will think so too, but that might not be the case, since you are likely not your audience). When you take some time to develop personas and scenarios before design then you are bringing all these assumptions out in the open. You can see if your assumptions are the same as your other team members. You can see if your assumptions can be validated.

2. Ensure you are designing what your audience needs & wants — How can you design what your audience needs and wants if you don’t know what they need and want?! When you go through the process of creating personas and scenarios you are collecting data on what people really need and want, not just what you think they need and want.

3. Design for what is critical & important, not the exception — The process of creating personas and scenarios is the process of deciding “if we can’t design for everyone doing everything then let’s concentrate on the most important users doing the most important things.” You have to identify what’s important, what’s frequent, what’s critical, and what’s an exception. Then when you design you can be sure you are designing for what 80% of the people need/want to do 80% of the time, instead of being distracted too much by exceptions — things that rarely occur or aren’t that important.

4. Communicate clearly — How many times have you left a meeting sure that everyone is all in agreement about the audience and the scenarios for the product you are designing. But if you don’t document those decisions they are easily forgotten, or they change over time. When you create personas and scenarios you have documents that you can use throughout the project to communicate clearly to other team members, as well as stakeholders, what the decisions and design parameters are.

 

What do you think? How do you think personas and scenarios help create great design? Are they used in your organization?

For more on personas & scenarios, you can watch the first couple of lessons of the new course for free.