Personas

Personas are representations of our *users*. They promote empathy by allowing us to focus on individuals rather than groups. It's this whole issue of empathy. We keep talking about "users". And even just talking about the *roles* like "customers" or "clerk" or "salesperson" doesn't make these roles seem real. It doesn't. We're not talking about real people. Real people have limited abilities.

Real people don't necessarily get computers in the same way that the development team does. Real people have needs that have been brought up by their circumstances or by their own personal beliefs. So, we need to know a bit *about* them. And personas are a great way of representing those understandings in the design of a real system. So, there is strong psychological evidence for *personal bias*. Our brains are wired to *empathize with individuals rather than groups*. The general feeling is that when we dehumanize people by referring to them

with these abstract collective nouns – because collective nouns *are* abstract by definition, so we're talking about "users" or we're talking about "customers" – we're taking the "people" away. We need to put the "people" back. Back in 1983, David Sears ran a study with two sets of participants. He gave the participants the same characteristics. And in one set of participants he said that these characteristics were of

*an individual*. And I believe he described the individual. And in the other set participants he said that these characteristics were of *a group of people*. And the participants who were told that they were seeing the characteristics of an individual *always rated the individual more highly* than the participants who rated the characteristics in connection with a group. So, that he called the *person-positivity bias*. And it basically is confirmation that our brains

– us as individuals – *prefer thinking about other individuals*. We're certainly more inclined to think more positively about other individuals than we are about collective nouns like "tourists" or "customers" or "users". The *scope-severity paradox* is a much more recent piece of work – 2010 – and is quite surprising. Two researchers, Nordgren and McDonnell, established that reactions to a fraud were more severe when it was presented with three victims rather than 30. So, it's the same kind of deal: two sets of participants,

both given exactly the same details of a crime, except that in one group they were told it affected three people and the other group were told it affected 30 people. And it was the people who were told that there were only three victims that thought that the crime was more severe. And they, on average, added a year on the prison sentence that the perpetrators of this crime should receive. So, again, that is just confirming this tendency for us to feel more strongly about individuals than we do about groups.

Personas are fabrications *based on research*. We mustn't let go or lose sight of that little parenthetical expression there, because we go out and we find out who these people are – the ones that we're interested in – find out what behaviors they have which drive them to need our solution, what motivations, what their circumstances are, what their contexts of use are,

just so we understand who we're building the solution for and other aspects that we describe in the context of use. These personas are representations of our users, who represent the goals, behaviors and motivations of those real users. They *promote empathy* by allowing us to *focus on individuals rather than groups*. So, instead of talking about "User Community One" or whatever catchy name we'd like to come up with for our user communities, we start talking about "Bob"

or "Jane" or "Elizabeth" – whoever – whatever everybody in the team is happy with. And there have been all kinds of documents and papers and studies written about personas. And you'll find that personas range from quite a limited description of a person. And, in fact, it can be just as little as changing the name "users" to a person's name. So, if you always refer to your customers as "Andrew", then you would actually

be doing yourselves a favor in terms of making that customer seem much more real. But at the other extreme it's not uncommon to hear about user research and persona development taking *weeks* – possibly even months: 2–3 months, which is, in my view and and quite a few others', certainly for an Agile environment well beyond the realms of possibility. So, we're going to be talking about something called a *minimal persona*. So, minimal persona – a name, age and other specific demographic details that a real person

would have. A photo – ideally realistic – showing the person in that setting or doing that thing. And then, basic information about why you're interested in them or why they're interested in us – our solution or product. So, their *primary goals*: *why* those are their primary goals and *what* they're hoping to achieve through our solution or product. And their *behaviors* – what are they doing before and after interaction with our solutions

fit with their daily routine, for example. And some of this comes from the fact that I have for years been astounded by how little the people developing software solutions know about their users. I've been involved in a couple of projects where there was no contact whatever. The development team had never met or seen a user, didn't know what the user was doing immediately prior to entering or receiving data from their system, didn't know what happened to the output data, knew almost nothing.

So, it wasn't surprising that the system when it was first launched was almost impossible to use, because it didn't actually fit. It was like having a random piece of a jigsaw puzzle and a very well-defined hole that it just did not slip into. So, these are the reasons we're trying to actually make sure that we understand at least something about our user communities. And that's what personas are trying to help us with. *Extended personas* – you might add lifestyle interests,

hobbies, as they apply to their motivations. I wouldn't add them just to make the person seem more complete. That isn't absolutely essential. But if some of those issues – lifestyles, interests or hobbies have an impact on your solution, then you should know about them. So, *keep to the details that are relevant* to the problem. Remember that we want to *motivate our team to help* our personas, *not* to drive them crazy with distracting detail, which is one of the complaints you will hear about personas.

Certainly when I've attended conference research papers on the use of personas in teams, often they were not well-received, because there just seemed to be so much of it – the persona specification. *Credibility*: ensure that the personas are *believable* and liked *as much as possible*. Certainly do *not* give personas unpleasant or dubious habits like being a heavy drinker or a heavy smoker or likes to bet on the horses – unless, of course, you're building a gambling app or something! *Change the name, photo and other details* until the whole team is comfortable with them.

It needs to be a collaborative effort between the user experience people and the people who are going to be using them. That would be the development team. So, the names and the photos are almost entirely arbitrary. If you've done research with a handful of participants, then you'd have a handful of photos. If not, then try to find photos from a stock photo site. But try to avoid overtly attractive people because it can be distracting. In user experience, we create often what are referred to as "design research personas",

or "design personas" for short. So, that's what these things are technically called. We go out and we research these user communities. We decide what behaviors and needs are relevant to us: Who are we building the solution for? And those personas are based on this design research. So, that's why we want to call them "design research personas" or "design personas". But there are lots of other things that also get tagged with personas.

And the most common of those I've come across, particularly in large companies, are *market research personas*. And they're not the same thing is the main problem that we have. So, beware that *other kinds of personas exist*, often based on demographics or market segmentation. These can be used for *validating design personas, but should never replace them*. There is little point in trying to reuse personas for different projects, as well, unless the same goals, motivations and behaviors are relevant.

And I've come across this whole approach in one particular vertical market in the U.K. And that is mobile phone service providers – that they have all got marketing personas based on age ranges. And they then attach labels to these age ranges to suggest how these people behave and what they need from our services, which, just to be honest, cannot really be true! You need to actually *forget about the demographics*. There will be some age-related behaviors, no doubt. But they shouldn't be

the motivating factors in the design of an interactive system, which is, after all, what we're trying to achieve. The main thing is that predominantly you have *one* or *two* primary personas. If you've got a project – and I've had people kind of come up to me almost in a boasting tone, saying: "Our project has got 20–30 personas!" And I'd say, "Oh, really? How is that?" They'd say, "Well, it's a hospital system." And the thing is, it's a *very* big system. And what you need to make it agile and to make these things work effectively

is to split the system into parts. So, you may well have some small number of primary personas that apply throughout. But in many cases you're going to have primary personas that are specific to that kind of system or that part of a system. So, let me give you some very simple examples. The one that I like to use is a hotel self-check-in. When I started writing about hotel self-check-ins, there were none in existence. And now I do come across them, funnily enough, in hotels that have got receptionists but all they do then is to

refer you to the self-check-in in front of the reception! I was motivated for this example by checking in at a conference hotel on one occasion. I actually got in pretty easily. I think it was a 20- or 30-minute process. But the next day I was walking through the reception and the queue – the line – of people waiting to check into this hotel went around the block. It was just utterly amazing. There must have been 200 or 300 people waiting to get in.

So, it occurred to me: "Well, why don't we just have some self-check-ins like we do at airports?" And, of course, self-check-in at airports is entirely bog-standard these days – it's what everyone does. So, for example, the primary persona of a hotel self-check-in service must be the customer checking in. It makes no sense for it to be otherwise. A *secondary persona* would be someone who is acting in a *supporting role* inside that system. So, a secondary persona might be a hotel manager or a receptionist or somebody who's

responsible for the upkeep of the hotel, for example. So, these are all *secondary roles*. They're not the people for whom we are building the system. They are people who are *involved in* the system and often in a backroom kind of interaction. These are people that primary personas rarely see or even know about. So, it's a difference between the primary roles in a stage production and just extras or people with non-speaking parts. That is kind of the difference between primary and secondary personas.

A lot of systems may have *only one* persona. This is the person that we're building this particular product for. And you can have all kinds of philosophical arguments about whether you're building a Swiss Army knife solution or whether you're building a carving knife solution. One is very good at one thing. Carving knives are very good at carving. Swiss Army knives are very good, but in a fairly different kind of way, at *all kinds* of things.

But they're not all that easy to use. So, it's up to you. The whole point of personas is to try to *give focus*. So, these are our customers. Other people, who do not fall into the definition or the descriptions of our personas, it's fine if they find our system easy to use. But unless we can actually identify some clear purpose in adapting the system to be more inclusive, then we would deliberately not pay much attention to their particular requirements. Now, things like *accessibility* and the *age ranges* of users – they fall outside the whole persona mechanism.

You must *always make sure that your systems are usable by those with disabilities* whether that's acknowledged specifically in your persona or not. I do have at least one colleague who, if they're dealing with a team who has little experience of accessibility – that is, systems that will be used by disabled people – he deliberately includes a disabled persona. But that really ought not to be necessary. But if that works for you, then that's absolutely fine, too.

Certainly I can see it being important when working with teams that don't have much experience. So, you must make sure that your solutions work for a *broad range of people* in terms of *accessibility* and *age issues*. But otherwise, we want to be very focused on the *specific behaviors* and *needs* of our primary personas. So, we stick to small numbers to maximize empathy. And we consider splitting larger projects, as I was discussing for the hospital example. For example, a hotel check-in system could be split into front desk and housekeeping projects

with separate personas. So, those could be two smaller Agile projects. And there is no magic number. But, like I have been saying, 1 or 2 primary personas is perhaps the most common, with maybe a few secondary personas thrown in, as well. Personas get used in all sorts of places. Obviously, their main focus is in *design*. So, "Who are we building this product for? How should the interactions take place? How much experience can we rely on them having of this kind of solution?" and so forth.

We will have to *recruit* these people. We want to do *research* with them, perhaps continuing research over several life cycles of the system. We want to recruit people for usability testing and user evaluation / usability evaluation in general, not just running them through early beta releases of the software. We might want to be testing with paper prototypes. We might be wanting to show them just wireframes and talking to them about the layout

and their understanding of the different components of the page and those sorts of issues. Sales and marketing will want to know *who* they should be targeting in terms of what the system does and for whom. And remember that you will need to describe the *demographics* and the *filtering questions* for your personas to a recruiter. So, when you're recruiting "Arthurs", what is it about Arthur that makes him your persona? It needs to be something that he wants or needs or you're *hoping* that he wants or needs. He needs a solution to a problem. So, what is that problem?

So, you need to actually talk to your recruiters about filtering questions. You know, what are you going to ask *potential Arthurs* that's going to help you to decide whether this person is really an Arthur? Now, this is quite an interesting area. And it may depend a lot on how enthusiastic your team is about personas. If you've done your job right, if you've *sold* personas, or if your team is already quite familiar and quite enthusiastic about personas,

then you might do some really fun things like getting mugs and coasters printed with maybe the face of the persona on one side and some of their relevant details with respect to your system on the other side. Ditto with mugs, maybe even T-shirts. And one thing that I was quite amused by – and I could actually see this working for some teams – is life-size cardboard cutouts. That's another possibility. So, you could actually have a room with your personas kind of standing around in unused corners.

I do know of organizations – I have heard of organizations – that would actually give the persona a desk, particularly if they were building a system for somebody in-house. And they might actually put all the stuff to do with that persona on the desk, just to make that person seem more real – you know. "Arthur would always be on holiday, but there's his desk" kind of thing. And I should mention – I'll just point out this very last thing – because it's quite important: at the very least, personas should appear in *easy-to-read* form on the project workspace

– whatever – sometimes, you'll hear this phrase – I used to hear it; I don't know that I've heard it very often – called "information radiators". Well, they're what you and I might refer to as "walls" or "partitions". They're the vertical spaces in your workspace. And you would pin important things to that, like all of the backlog for the next cycle and the design maps. So, these are things which everybody who's working on the project would actually be able to refer to quite readily. You might even hand these out in laminated plastic form,

just so everybody has easy access to them, for example.

So, you've gone out, you've talked to your users. You've done a field study, basically interviews, user interviews and observations of their tasks, of their environment. And what do you do with that? Personas and journey maps. So, I just wanted to talk a little bit about personas in particular. Journey maps are also important, but I'm just going to cover personas. Where you get your data from is hugely important. Most people just use surveys.

Some people use focus groups. Those are both market research techniques. They're not appropriate for UX. Why? Because in UX we're looking at *behavior*, not at opinion. And focus groups and surveys do a lot of opinion elicitation. They're fine for marketing, but they really have no place in UX. So, if you do market research and just use  like a segmentation approach or market research approach, you're going to end up with a different type of persona.

So, if you do field studies, you'll end up observing their behavior and then creating behavioral profiles or role-based personas, and you'll understand better the context and the conditions under which your mobile app or device mobile content  is being consumed. And that's super important. This is an example of a persona, and you can adjust a persona. But basically you have a scenario. I've started writing my personas in first person.

So, literally the notes I take, I'll build the persona based on actually what the user said. And it's about 98% verbatim, like what they said with a few corrections of – you know – grammar and stuff like that. I won't change the meaning. I won't remove the words from their mouth and rephrase them in my head. I won't alter or fabricate them. And it's a technique that I learned from  Whitney Quesenbery, a UX consultant

who's written a book about storytelling and personas in particular, because personas are really about *stories*; they're really about telling stories about that context. Try it right now. So, think about the personas that might, the roles that people, the problems they might solve with your app. And in a narrative kind of style, write one or two sentences on their background to kind of set the context; write two or three more sentences on the problems that they're trying to solve, like the tasks, and two or three sentences on the call to action,

like what they need, what their desires are or how the design can basically help them get to their task, how can it empower them? How you can meet their needs, their goals, their tasks, their sub-tasks? If you have a lot of questions, it's probably because you need to spend more time with your users. Once you start hanging out with users doing field studies, you get to know what they need and the context of use becomes very apparent.

It's one of the most enlightening things I think about personas. But also you understand their *distractions*, their deeper kind of emotional and social context. You understand what multi-tasking they might be doing and what problem solving or the different states, the varied states that they might use, kind of usage scenarios, if you will,  but in different states. So, to create a role-based persona, identify the personas based on your data, so the themes that come out, the different hats that users are trying to wear.

And then give them a name, like not just like Sally or Susan or Jim or John or something. But give them an associating  adjective such as Support-Seeker Sally or Finance Fiona, I think was that other one there. Okay, so continuing with persona development, think about these things: *environmental impact*, so the context of use; *cognitive impact*, the time, for example, the time pressure or stress that they might be under.

Think of the *social impact* – the triggers that might lead to that such as another user or somebody else online or started a chat or tripped off – I don't know – a support call or whatever. And finally the *behavioral impact* – so, for example, the roles that not just the user has but the roles that the user must assume to complete the task. There's also *mental models*. So, mental models being these past expectations

that users bring to their designs; they basically influence how a user problem solves. And think about like the mental model for the restaurant experience – you know – what does that look like? For example, you enter the restaurant; there might be waiting, you might have to check in, you may have to order ahead, you might have a pickup situation. Some restaurants have made a separate place for the food delivery people to go

so that they're not standing there waiting with the the diners that are coming to the restaurant for the "live food". You can conduct *task analysis*, which is asking the user to do the task. You know – you can accompany them, a doctor's visit, restaurant visit, whatever it might be. You can accompany the user and look for the language they use, the way they talk about it, look at the physical, social environment, look at their functional needs and priorities and maybe  even the cognitive demands that they have.

So, for example, they have to figure something out; they have to fill in a form. They have to submit this. There's a pressure to answer these questions or to know something. Look at the task space, how they're making sense of things, how they're deciding or solving problems for themselves. Remember, we don't just have goals and tasks, but we have *sub-tasks* as well. So, we need all three of those things, not just goals. It's so important that we make sure that we drill deeper down

into our users' behavior so we fully understand what it is and bring that out. So, doing that, though, is so well worth it and makes you a much smarter designer and a much smarter design team.

Personas are one of these things that gets used  in very, very many ways during design. A persona is a rich description or description of a user. It's similar in some sense, to an example user, somebody that you're going to talk about. But it usually is not a particular person. And that's for sometimes reasons of confidentiality.

Sometimes it's you want to capture about something slightly more generic than the actual user you talked to, that in some ways represents the group, but is still particular enough  that you can think about it. Typically, not one persona, you usually have  several personas. We'll come back to that.   You use this persona description, it's  a description of the example user,   in many ways during design. You can ask  questions like "What would Betty think?"

You've got a persona called / about Betty, "what would  Betty think" or "how would Betty feel about using this aspect of the system? Would Betty understand this? Would Betty be able to do this?"   So we can ask questions by letting those personas  seed our understanding, seed our imagination.   Crucially, the details matter here. You want to make the persona real. So what we want to do is take this  persona, an image of this example user,   and to be able to ask those questions: will  this user..., what will this user feel about  

this feature? How will this user use this system  in order to be able to answer those questions?  It needs to seed your imagination well enough.  It has to feel realistic enough to be able to   do that. Just like when you read that book  and you think, no, that person would never   do that. You've understood them well enough that  certain things they do feel out of character. You need to understand the character of your  persona.

For different purposes actually, different levels of detail are useful. So I'm going to sort of start off with   the least and go to the ones which I think are  actually seeding that rich understanding.  So at one level, you can just look at your  demographics. You're going to design for warehouse   managers, maybe. For a new system that goes into  warehouses. So you look at the demographics, you might have looked at their age. It might be that on the whole that they're   older. Because they're managers, the older end. So  there's only a small number under 35. The majority  

are over 35, about 50:50 between those who are in  the sort of slightly more in the older group.  So that's about 40 percent of them in  the 35 to 50 age group, and about half   of them are older than 50. So on the whole  list, sort of towards the older end group.   About two thirds are male, a third are female.  Education wise, the vast majority have not got   any sort of further education beyond school. About 57 percent we've got here are school.  

We've got a certain number that have done basic  college level education and a small percentage   of warehouse managers have had a university  education. That's some sense of things.   These are invented, by the way, I should say, not  real demographics. Did have children at home. The people, you might have got this from some big  survey or from existing knowledge of the world,   or by asking the employer that you're  dealing with to give you the statistics.   So perhaps about a third of them have got children  at home, but two thirds of them haven't. 

And what about disability? About three  quarters of them have no disability whatsoever.   About one quarter do. Actually, in society  it's surprising. You might... if you think   of disability in terms of major disability,  perhaps having a missing limb or being   completely blind or completely deaf. Then you start relatively small numbers.   But if you include a wider range of disabilities,  typically it gets bigger. And in fact can become  

very, very large. If you include, for  instance, using corrective vision with   glasses, then actually these numbers  will start to look quite small.  Within this, in whatever definition they've  used, they've got up to about 17 percent with   the minor disability and about eight percent  with a major disability. So far, so good. So now, can you design for a  warehouse manager given this? Well,  

you might start to fill in examples for  yourself. So you might sort of almost like   start to create the next stage. But it's hard. So let's look at a particular user profile. Again,   this could be a real user, but let's imagine  this as a typical user in a way. So here's Betty Wilcox. So she's here as a typical user.  And in fact, actually, if you look at her, she's   on the younger end. She's not necessarily the  only one, you usually have several of these.  And she's female as well. Notice only up to  a third of our warehouse ones are female. So  

she's not necessarily the center one. We'll come  back to this in a moment, but she is an example user. One example user. This might have been  based on somebody you've talked to, and then you're sort of abstracting in a way. So, Betty Wilcox. Thirty-seven, female, college education. She's got children at home, one's  seven, one's 15. And she does have a minor disability, which is in her left hand. And  it's there's slight problem in her left hand.  

Can you design, can you ask, what would Betty  think? You're probably doing a bit better at   this now. You start to picture her a bit. And you've probably got almost like an image   in your head as we talk about  Betty. So it's getting better.   So now let's go to a different one. You know, this  is now Betty. Betty is 37 years old. She's been a   warehouse manager for five years and worked for  Simpkins Brothers Engineering for 12 years. She didn't go to university, but has studied  in her evenings for a business diploma.

That was her college education. She has two children  aged 15 and seven and does not like to work late.   Presumably because we put it  here, because of the children.   But she did part of an introductory  in-house computer course some years ago.   But it was interrupted when she was promoted,  and she can no longer afford to take the time.   Her vision is perfect, but a left hand movement,  remember from the description a moment ago,   is slightly restricted because of an  industrial accident three years ago. 

She's enthusiastic about her work and  is happy to delegate responsibility   and to take suggestions from the staff. Actually,  we're seeing somebody who is confident in her   overall abilities, otherwise she wouldn't  be somebody happy to take suggestions.   If you're not competent, you don't. We sort of see that, we start to see a   picture of her. However, she does feel threatened  – simply, she is confident in general – but she   does feel threatened by the introduction of  yet another computer system. The third since she's been working at Simpkins Brothers. So now, when we think about that, do you have a better vision of Betty?

Do you feel you might be in a position to start talking about..."Yeah, if I design this sort of feature, is this something that's going to work with Betty? Or not"? By having a rich  description, she becomes a person. Not just a set of demographics. But then you  can start to think about the person, design for the person and use that rich human understanding you have in order to create a better design.

So it's an example of a user, as I said not  necessarily a real one. You're going to use this as a surrogate and these details really, really matter. You want Betty to be real to   you as a designer, real to your clients as you  talk to them. Real to your fellow designers  as you talk to them. To the developers around  you, to different people. Crucially, though, I've already said this, there's not just one. You usually want several different personas because the users you deal with are all different.

You know, we're all different. And the user group – it's warehouse managers – it's quite a relatively narrow and constrained set of users, will all be different. Now, you can't have one persona for every user,   but you can try and spread. You can look at the range of users.   So now that demographics picture I gave,  we actually said, what's their level of education? That's one way to look at that range. You can think of it as a broad range of users.

The obvious thing to do is to have the absolute  average user. So you almost look for them:   "What's the typical thing? Yes, okay." In my  original demographics the majority have no college   education, they were school educated only. We said that was your education one,   two thirds of them male – I'd have gone for  somebody else who was male. Go down the list, bang   in the centre. Now it's useful to have that center  one, but if that's the only person you deal with,   you're not thinking about the range. But certainly you want people who in some sense  

cover the range, that give you a sense  of the different kinds of people.   And hopefully also by having several, reminds  you constantly that they are a range and have   a different set of characteristics, that there  are different people, not just a generic user.