Empathy Mapping

Do you know this feeling? You have a plane to catch. You arrive at the airport. Well in advance. But you still get stressed. Why is that? Designed with empathy. Bad design versus good design. Let's look into an example of bad design. We can learn from one small screen.

Yes, it's easy to get an overview of one screen, but look close. The screen only shows one out of three schools. That means that the passengers have to wait for up to 4 minutes to find out where to check in. The airport has many small screenings, but they all show the same small bits of information. This is all because of a lack of empathy. Now, let's empathize with all users airport passengers,

their overall need to reach their destination. Their goal? Catch their plane in time. Do they have lots of time when they have a plane to catch? Can they get a quick overview of their flights? Do they feel calm and relaxed while waiting for the information which is relevant to them? And by the way, do they all speak Italian? You guessed it, No. Okay. This may sound hilarious to you, but some designers

actually designed it. Galileo Galilei, because it is the main airport in Tuscany, Italy. They designed an airport where it's difficult to achieve the goal to catch your planes. And it's a stressful experience, isn't it? By default. Stressful to board a plane? No. As a designer, you can empathize with your users needs and the context they're in.

Empathize to understand which goals they want to achieve. Help them achieve them in the best way by using the insights you've gained through empathy. That means that you can help your users airport passengers fulfill their need to travel to their desired destination, obtain their goal to catch their plane on time. They have a lot of steps to go through in order to catch that plane. Design the experience so each step is as quick and smooth as possible

so the passengers stay all become calm and relaxed. The well, the designers did their job in Dubai International Airport, despite being the world's busiest airport. The passenger experience here is miles better than in Galileo Galilei. One big screen gives the passengers instant access to the information they need. Passengers can continue to check in right away. This process is fast and creates a calm experience,

well-organized queues help passengers stay calm and once. Let's see how poorly they designed queues. It's. Dubai airport is efficient and stress free. But can you, as a designer, make it fun and relaxing as well? Yes.

In cheerful airport in Amsterdam, the designers turned parts of the airport into a relaxing living room with sofas and big piano chairs. The designers help passengers attain a calm and happy feeling by adding elements from nature. They give kids the opportunity to play. Adults can get some revitalizing massage. You can go outside to enjoy a bit of real nature.

You can help create green energy while you walk out the door. Charge your mobile, buy your own human power while getting some exercise. Use empathy in your design process to see the world through other people's eyes. To see what they see, feel what they feel and experience things as they do. This is not only about airport design. You can use these insights when you design

apps, websites, services, household machines, or whatever you're designing. Interaction Design Foundation.

As an interviewer, I think it's important to go in with an attitude of *openness*, with an attitude of *wanting to learn*, of *respecting the expertise* of your interviewee, whatever kind of expertise that is, and wanting to learn from them. I sometimes perhaps take that to extremes.

But I think that an important part of interviewing well is to listen to people and not to come with preconceptions about what they're going to say or what they can share. And the other, of course, is about an interviewing style that's open and respectful and *not aggressive* to people so that they do feel relaxed and able to say things and not feel judged for what they're sharing and what they're saying.

So, quite a lot of my research now is around health technologies, particularly. So, that can lead into some fairly sensitive topics. We've done projects looking at how people might use technology to manage their alcohol consumption or their exercise or their diet. And these are all topics that people can feel very defensive about. You know – "How dare you suggest I drink too much or I'm a couch potato or I eat too many carbs!" or whatever.

You know, they're topics where people *can* feel judged. But if people feel judged, then they're not going to give you a real understanding of how you might design technologies that will *really* help them. And so, it's really important to *not* be judgmental – to be open, to respect where they're coming from

and to understand what matters to *them*, as opposed to what you think should matter to them. Well, I certainly work quite hard with students to try to get them to question their own assumptions and not to expose their assumptions when they're interviewing – so that they are actually open to hearing what people are really saying, what people are really trying to express.

Another point is if interviewers are not *intentionally* leading. By coming with too many assumptions about what you're expecting people to care about or expecting people to say, you can unwittingly lead people quite a long way. And leading questions will result in you hearing what you expected to hear, which doesn't necessarily give you the information that you actually need to gain insight from any study.

And surely the point of doing interviews is to get some insight that you didn't already have. If you already knew the answer, there'd be no point in interviewing people about the topic, whatever it is. D.H.: You always have assumptions, right? Otherwise, you wouldn't do a study. A.B.: Yes. D.H.: So, what's the best way to sort of balance or use your assumptions in a constructive way? A.B.: So, I think what you try to do is to have questions more than assumptions.

A *qualitative* study I think is driven by a *question*. *Quantitative* studies are more often driven by a *hypothesis* – i.e. you have a belief and you want to test it – whereas qualitative studies are much more driven by questions. And I've certainly got partway through several studies and suddenly realized that I had a set of assumptions

that aren't necessarily valid. And so, I'm forced to question my own assumptions.

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.

Ditte Hvas Mortensen: Are there some common pitfalls that you should be aware of when your search for themes? Ann Blandford: *Confirmation bias* is, I think, the biggest one: that you think you've spotted something fairly early on in the data, which, particularly if that's something that supports a pre-existing assumption that you had – you know – before starting the study.

And so, it's so much easier to spot data that supports that position than it is to spot data that contradicts it, particularly if the contradiction is a little bit kind of *tangential*. So, that's why I kind of emphasize that you have to look explicitly for contradictory evidence in the data because that can be harder to spot. So, you have to ask yourself specifically "What would contradictory evidence look like?"

or "What *might* it look like?" You know – "Is there any of that? *Why* might it be there?" So, I think confirmation bias is the biggest. Another trap is there's one participant with slightly outlandish but very engaging and exciting views,

and they express themselves in a wonderful way, and you almost start writing the narrative as if that person is the central figure – as opposed to being a slight outlier in the data set. And so, their perceptions and their attitudes and values are given more *weight* than those of perhaps less articulate or less extreme participants. D.M.: Are there any other sort of common problems that you often experience students have when they do analysis?

And do you have some good advice for how to tackle those problems? A.B.: I think the big one is the one I've already mentioned – about getting overwhelmed by the data and not really knowing where to start or when to stop; having so many themes and not being prepared to let go of any of them;

or having difficulty working out which ones matter and which ones don't. And *data gathering* for some people is more exciting than data analysis. In practice, a good analysis takes longer than data gathering.

It takes longer to analyze 10 hours of interview data than it does to gather 10 hours of interview data, *even* when you take into account the time it took to recruit 10 appropriate participants in the first place, which can be non-trivial. But analysis is much more of a solitary activity, whereas data gathering is inherently social. You know – you're interviewing people; you're learning things; it's fun and engaging.

So, some people can get quite bogged down in analysis, I think. And it feels like a huge task, and you need to break it down into *small steps* of – you know – "I'll deal with three pages of data today." – you know – or, "I'll do *this* step of coding." or, "I'll do this little bit of stuff." You've got to break it down into manageable chunks.

And also, just dive in and *do* some, actually, you know. The longer you leave it – and it's just this pile of transcriptions or whatever – you know, the harder it is to get started and the more overwhelming it can feel. So, I think *feeling overwhelmed* is probably the biggest challenge, and not being prepared to drop themes or not being able to quite see how themes fit together to tell a bigger story.

That's of significance for HCI research or for technology design. And going off on a weird tangent in the analysis, and forgetting why you were doing the study in the first place. So, with those, I think the best way to deal with it is to *talk to people about it* – you know – to get somebody else involved,

even in just talking through ideas with you.