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.
And I will give you those references.
This is something that Stalin said a long time ago,
but it's not just Stalin:
"If one man dies of hunger, that is a tragedy.
If millions die, that's only statistics."
But we have other studies,
which are much more recent than Joseph Stalin.
But 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.
I think 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.
Then, 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.