Personas – my frenemy

Personas – my frenemy


“Personas” is one of those buzzwords that you’ll often hear in meetings, no matter if UX professionals are present or not. As one of those methods non-UX pros (seem to) know, its usually one of the first things that come up. Personally the word alone triggers an unvoluntarily eye-roll. Don’t get me wrong, the idea behind personas is totally fine and it can be the most important document for user analysis, but I have never seen it treated right in any project.

The basics

Personas built the base in understanding users. Basically you develop a bunch of virtual identities with psychologial characteristics, behaviors and demographics of your target groups. By giving characteristics a name and sometimes even a face (even if only a stock photo one), you can easily make the data more comprehensible for everyone involved. At every state during the project you can (and should) bring them up to find the best solutions. Always ask yourself questions like: “Which option of these design-drafts would help this persona the most?” and “Does one of these option make the app unusable for one of the personas?” I admit, having these imaginary friends may seem weird, but it can help a lot. As I have stated before: You are not the user and you have to find an optimal solution for the actual users. The right use of personas can and will increase the success of the final product directly.

The DO

In what detail you write your personas is totally up to you, the only important thing is: everything has to be relevant for your project. If possible, use existing product usage data.

  1. The first step is always a look at your users. Examine existing usage of your app, website, whatever or define who your target group is.
  2. Segment these users in logical groups based on their behavior. How detailled or small your groups are is up to you. Basically its a good way to start with some bigger groups (like “people in backoffice who enter data” and “people in sales who need to look up infos”). If you’ve done context analysis, you have already a pretty good picture of your user groups, sometimes even too detailled. Try to find a way that makes sense for your project.
  3. With the existing data and information from user interviews you can form the persona. Collect the information and give them a name and a nice stock photo as a face. These tend to be cliché and over the top, but that’s totally fine.

I’d like to do the first two steps of personas twice: At first we try to define the target groups by ourselves or based on extisting data. On that, I go into user analysis and context interviews. During the interviews and their analysis the existing segments of users will be confirmed or adjusted according the information of the interviews.

What kind of data you show is also up to you and to your project. Most of the time it makes sense to include the following:

  • Photo and Name: Use a stock photo, avoid celebrities or pics of people you know. The name should be “real”, too. “Jonas Edison” is better than “Jonas the power user”. After all you have to think of them as real persons.
  • Demographics: While demographics do not always have relevance for the project itself (since there are not specific enough for some projects), it helps imagining the person. If it states “45, male, married, 2 children”, you’ll have a certain picture in mind.
  • Characteristics: give the persona character by stating a few relevant adjectives. “spontaneous”, “thoroughly”, “always in a hurry”. Try 5-6 for each persona, don’t overdo it.
  • Expertise: State how long the person works in his field and how high the affinity with technology is. It’ll help you find the right level of complexity in both content and functionality.
  • Context: in 2-3 sentences, what’s the context of this person. “Alina works at the front desk of the hotel, she uses a stationary pc with 2 monitors, which she shares with her two colleagues.”
  • Motivation: This is maybe the most important thing. State what the user expects. “Alina wants to access data quickly, she often has to multitask (do various tasks at once). She needs to save her progress in between to not loose anything.”

Once you’ve finished these, you can place the different personas in a matrix or spectrum scales. Based on what’s useful for your project. At least print them all out and place them in a prominent space in your office, everyone involved has to see them everytime.

The DON’T

Ok, that sounds pretty good right? With every decision coming up, you can take a look at your personas and ask yourself, what would be best for them. Great – in theory… However, as I said before, I have a love-hate relationship with them, because I’ve never seen them work properly in projects. Not because the method is faulty, but because there are some things that can totally ruin personas. Let’s take a look at some:

 > Letting a non-UX-pro write them. <

This happens pretty often. I come into a project, where the client or my colleagues have already made some progress. Nothing bad in that, but very often, they have over-eagerly already done the Personas… and often don’t understand that I’d have to redo them, which will take time… [enter exhausted silence here]… Really, I appreciate interest in UX and Usability very much. But if a non-UX writes them, they are most of the time unusable in the UX sense. And that’s totally understandable. Marketing, business development, sales… they all have a very different view on the users and customers. But what can a UX-pro do with informations like “Kathy, 25, sporty and ambitious”? Target groups, that are useful in marketing, don’t make sense for usability work, esp. not for specialised projects. Personas have to be created based on user groups of this specific case and their behaviour.

> Wishful thinking. <

It is tempting, I admit that. But if personas are not based on real data, they will not work properly. It may be the shorter way to write personas based on assumptions. But if you can’t prove your assumptions, what are those more than wishful thinking?

> Putting them to the bunch of other documents. <

No matter how good your personas are done, if you just save them in your project folders, you could have put better use to all that time that went into them. It would be a perfect world, in that your team (and often even yourself) will dig them out and look at them all by themselves. And that can be one of the biggest mistakes. Personas have to be a constant reminder to think of the user. And as such, they better be constantly visible. Pinned to the wall of your office AND printed and brought to every (!) meeting. Not that you’ll need or use them every time, but having them with you will remind you!

Giving up. <

Rationally we all know that change takes time. And it takes time to form a new habit. It’s the same with implementing any method. At first, take the time for yourself. Learn how to do personas, it will be trial and error in the beginning. And that’s totally fine. And second, be persistent. If your first try, or the first project with personas does not work that well, don’t throw the method away and don’t let others tell you to give it up. You and your team will need time to learn how to work with this method.

+ There are no comments

Add yours