
Why Personas Fail - adrian_mrd
https://www.nngroup.com/articles/why-personas-fail/
======
swanson
The criticism that opened my eyes to the issues with Personas was this example
from Alan Klement:

> Why did Alan buy the Snickers candy bar?

A. Alan is a thirty-five year old; has a degree in marketing; likes peanuts,
chocolate, nougat, and caramel; loves Snickers, eats one every day; has an
active lifestyle; drives a Honda; aims to retire from age 55

B. Satisfy his hunger

\---

My other insight was that many UX firms treat artifacts like Personas as the
deliverable. It is something concrete to show the value of the time and money
spent doing research. But it is a deliverable that has almost no value to
improving the product. The point of doing user research is to improve the
product, not to produce a beautiful 20 page "research document". But
translating user research from interview into fully-realized and delivered
features is _hard_ , and emailing a PDF of personas is comparably much easier.

~~~
drdrey
"Satisfy his hunger" does not explain why he went for Snickers and not a
different candy bar or an apple.

~~~
cuchoi
I would say that about 20% of the time that I buy a Snicker bar is to "satisfy
my hunger". I usually buy it as a treat for myself.

~~~
magic_beans
I'm amazed that anyone would choose Snickers if they were hungry. It's just
sugar -- eat a snickers bar and you'll be hungry again in 20 minutes. Is this
not common knowledge?

I myself would only buy a Snickers if I was having a stressful day and needed
something to make myself feel better.

~~~
dragonwriter
> I'm amazed that anyone would choose Snickers if they were hungry. It's just
> sugar -

No, almost half it's calories are from fat.

~~~
sudouser
he meant by weight its over 64% sugar. Fat is a third of calories —36%— not
half.

~~~
dragonwriter
The nutritional info I found online has, for a particular size, 215 Cal, and
11 g of fat. 11 g of fat is 99 Cal, which is 46%, not 36%.

------
bambax
In my former life as a consultant I came to very much dislike personas as
implemented by ux designers.

Personas are a magnet for prejudice: they are based on the idea that clusters
of people all behave the same (old people, young people, professionals, stay-
at-home mothers, what have you).

This very idea is, I think, flawed. If we really need to sort people into
groups, then we should use criteria based on what people are trying to achieve
_right now_ , not inherent characteristics that are supposed to
influence/define their behavior all of the time.

Therefore it would make more sense to have _just one_ typical user, with
different attitudes based on her -changing- goals.

~~~
king_magic
I’ll throw out another (admittedly anecdotal) issue - cost and effort to
develop something that - in my experience - isn’t all that valuable in the
end. In my life as a consultant I’ve watched a team of UX ‘experts’ churn for
2 weeks over a set of 5 personas. Jaw dropped every time we would check in -
this is what you spent the last 3 days on? Even more stunning was the client’s
reaction to the 3rd review of those personas. It was the same 1hr convo as the
previous 2 reviews, and no one seemed to think this wasn’t a massive waste of
time and their money. After the personas were done, no one ever referred back
to them for the remainder of the project. It was one of the greatest ‘value
minimization’ excersises I’ve seen in my career.

~~~
mistermann
Reminds me of a RACI matrix experience.

~~~
WaxProlix
RACI can at least be useful for defining who should be in what meetings early
on, how communications should go out, and even CYA later on in the project. It
can be good to have investment levels explicitly defined.

~~~
mistermann
There are probably plenty of places it's useful that I've just never been
exposed to, but I bet for every one of those, there's two or more others using
it who don't need it, but only because they were sold it by management
consultants at a lean management training course or something like that.

------
0xcde4c3db
Similarly, I hate it when vendors organize their site according to what they
expect their customer's line of business to be, rather than the features that
actually distinguish their own product or service lines. For example,
AppliedMicro divides its products page into "data center", "carrier", and
"embedded". So instead of browsing (or - dare I dream? - parametrically
filtering) the product lines to find something with the features I need, I
have to decide which hat I'm supposed to be wearing to be sold the right
thing.

~~~
donatj
Yes. I particularly hate when I am in none of the categories yet want the
product or service. Makes me feel like they have no interest in selling to me
right off the bat.

~~~
TeMPOraL
> _when I am in none of the categories_

Or, equally annoying - when you're in more than one at the same time.

------
OscarTheGrinch
I've done a few sessions using personas and can see little benifit to justify
the time expended upon them. If generated out of thin air rather than from
actual users it's just an exercise in exploring the teams predudices rather
than any external market needs.

~~~
Angostura
Point 3 in the article:

>In order for stakeholders to use personas, they have to believe in them, feel
invested, and have ownership over them. The most successful personas are
created with involvement from their end users. Otherwise, people will have no
understanding of the data behind them and the rigor that went into creating
them. Coworkers may think that the UX team just went away and played story
time for a few weeks, emerging with these fake people and asking everybody to
play along. That is NOT the attitude we want to foster.

>To avoid this pitfall, you must include the persona end users in the process
of creating personas. Invite stakeholders to sit in on a research session.
Send out a daily recap of the activities undertaken to create the personas.
Help people see how your research uncovers the customer segments early on, so
that when you roll out the personas there is built-in investment in their
validity and value.

~~~
dhimes
_In order for stakeholders to use personas, they have to believe in them, feel
invested, and have ownership over them._

I've done this a few times and no matter how convinced I was it was, in the
end, pure fantasy.

 _The most successful personas are created with involvement from their end
users._

I don't know what they mean by success: I tried to use personas to understand
customers I _didn 't_ have.

------
adrian_mrd
Important to differentiate between personas as archetypes and those based on
stereotypes. The difference? Solid, hard-yards user research that comes from a
large enough sample set.

~~~
superhuzza
"Solid, hard-yards user research that comes from a large enough sample set"

Unfortunately, not so simple in my experience. That's a lot of time and money
many companies can't or will not fork over. So, shortcuts and approximations
are used as an alternative.

~~~
adrian_mrd
Agree, unfortunately that is the tricky aspect: evaluating the cost/benefit of
undertaking user research (with personas as one aspect, along with diary
studies, interviews, observational studies et al - depending upon the nature
of the tasks/problem to solve.

What definitely costs companies a huge amount of time and money is launching
new products or concepts into markets - especially without some form of pre-
qualification i.e. is there a need? does this solve a problem? will customers
actually pay for this service? etc.

As the old user experience adage goes: "spend $1 on usability and save $100*
down-the-track".

* made up numbers :)

------
lmm
Interesting how hardly any of this page is specific to "personas". Anything
created without a clear intent to use it, or created in a silo and then
imposed on the rest of the organisation, is likely to fail.

~~~
ddebernardy
That's unfortunately how it's often done in orgs.

It's not just large orgs, either. I've lost count of the number of startups
I've interacted with that had barely if ever talked to their own users.

~~~
hinkley
It’s more fun to play what-if with your fellow devs. We like to blame everyone
else for feature creep but we add plenty of our own too.

That’s a big part of what personas are for. To get out of analysis paralysis,
and stop adding features that add combinatirally to the complexity of the app.

~~~
ddebernardy
Heh, marketers play what if games too. The good ones just actually test their
hypotheses (just like good devs).

------
jkaljundi
Their older article of matching personas with Jobs-to-Be-Done has always been
a good one: [https://www.nngroup.com/articles/personas-jobs-be-
done/](https://www.nngroup.com/articles/personas-jobs-be-done/)

So is Intercom's: [https://blog.intercom.com/when-personas-fail-
you/](https://blog.intercom.com/when-personas-fail-you/)

It also depends where you use these. While personas are often low value in
product design and UX (where JTBD can shine), in marketing and sales personas
can be a big help (although even there, JTBD has strong role).

------
bayonetz
A lot of straw manning in this thread. Personas can be a very useful way to
characterize your product's users. There are other ways as well. Each have
their pros and cons. Personas are great for deriving a small covering set of
concrete user types that can be used to guide and sanity check your design
choices. It allows you to gather a bunch of user requirement info once and
package it in a reusable way such that you don't have to do new research for
every new design choice that pops up.

Have a new new design question about user needs or motivations? Consult your
personas.

If the personas don't answer the question? Do some additional research and
expand your personas.

Personas not the right fit for the question? No problem, use another tool like
classic functional user requirements for this question.

Personas for food ordering apps demonstrate the usefulness nicely. You want to
know the preferences that segment your users like restaurant quality, cost,
and healthy options as well as demographics like age and income. From this you
can derive a few clusters, and ultimately personas. Useful ones like "Jeff,
the young workaholic that needs dinner brought to the office each night" or
"Tom and Sarah, parents trying to find decently healthy takeout options for
their kids". Now you can ask questions like, "do we have enough healthy
options that Tom and Sarah's kids will like?" and "do we have an easy way for
Jeff to reorder weeknight meals? Do we need a subscription plan?" You can do
similar things with other user research tools but personas are very natural
and intuitive for many scenarios.

------
snowwrestler
Although this article talks about them from the perspective of UX, personae
are fundamentally a marketing concept. They are simply a handy abstraction to
help non-experts reason consistently about market segments.

This is like using the idea of "selfish genes" to help people reason
consistently about natural selection. We don't think that genes are actually
selfish, any more than we think that all customers fit into a few neat
buckets. It just tricks the mind into adopting a different perspective.

It matters for product UX because your product will only serve the people who
experience it, and people will only experience your product if you market it
to them. (This is often where developers, who tend to look down on marketing
and PR, fall off this wagon. But it is largely true.)

If you want a basic concrete example of the value of personae, then compare
the bathrooms at an elementary school vs a bar. You're not going to position
the fixtures the same way in both. But in order to reason about that, you need
to first know who is coming into the respective establishments, and why.

~~~
shostack
As a marketing person, I can confirm that they can often be a useful
abstraction, particularly when collaborating with people who need to get the
general direction of an audience, but aren't necessarily data nerds who need
to be intimately familiar with the detailed demographics, psychographics,
technographics, behavioral data, etc.

They absolutely have limitations and can overly simplify things to a fault
sometimes, but as long as everyone gets that it is a representation and not
the absolute, they can help streamline things.

------
pure-awesome
This reminds me of a scathing and hilarious blog post about personas from
2013, where I actually first came across the concept:

[https://qntm.org/personas](https://qntm.org/personas)

~~~
TeMPOraL
A golden quote by the author, from the comments section:

> In the end, there is only one user story: "As a human being, I wish to
> breathe, drink, eat, procreate and accomplish other, more abstract tasks _of
> my own choosing_."

(Emphasis mine.)

~~~
brango
> _of my own choosing_

Billions of marketing dollars are spent influencing people to make them
"choose correctly".

------
weego
Personas are always just a projection of bias whether from the UX team or from
stakeholders. They are absolutely a useful tool, but often abused.

Too often I saw tickets written by product owners with stories like "As user
type X I want to be able to do Y when I'm in this situation" where there was
no empathy in correlating the actual functionality with anything to do with
the persona and they literally just wanted that functionality in the system.
Which is fine, but at that point admit your persona system is bullshit and
you're just doing opinion lead development.

------
toss1
While Personas may plausibly work as an aide for marketing program development
(a convenient way to abstract audience preferences), it is fundamentally
doomed as a useful UX design concept.

Any product or software is a TOOL to get things done. The UI is the exposed
interface to allow that work to be done, whether it is the deign of the handle
on a hammer, or the menu/button/etc. structure. The good UI makes it obvious
and easy to perform the actual task or tasks for which the tool is intended.

A "Persona" is simply too vague a spec to provide guidance on how to design a
more usable tool. What is needed is a clear concept of the tasks to be done,
not some abstract set of demographic characteristics, motivations and
attitudes.

~~~
juliushuijnk
UI design is not the same as UX design, important difference and potentially a
source of misunderstanding. If you are at the point that you know that a page
with a certain purpose needs to be made, then the UI is often not that hard to
design and you can make use of best practices, a/b testing, etc.

But for UX design, you also need to figure out the "clear concept of the tasks
to be done". Taking the perspective of the persona helps you define the list
of tasks to be done. If a hammer is needed, a screwdriver or a phone (to call
someone who can build things).

All people in the creation process have an idea about who that user is and
what their needs are, by making it explicit you make sure you are all on the
same page building the same thing.

~~~
juliushuijnk
To add a metaphor; when you design a class, you could say 'all i need is to
know the purpose of the class, the API is enough'. But how would you define
the API if you don't have a deep understanding of what the higher level
purpose is of the class? The architecture used, related classes, etc.

Perhaps the class you want to work doesn't actually needs to be built at all
because it will be never called!

Same goes with UX, it's first about the knowing the purpose of the program,
architecture, the content, how it's related, etc, then you try to define the
classes ('pages') and their API's ('what needs to be done on the page'). Once
you know that, often the class ('the UI') is probably easy to build. But
you'll probably make a better class if you understand why it exists in the
first place.

~~~
toss1
Agree that this is a higher level of design abstraction.

Yet, I still do not think that it is a high enough level of abstraction for a
Persona to be useful (you need to get out to marketing, if they're ever
useful).

Even at the 'What classes/pages/workflows do I need' stage, what you really
need is living users who are domain experts who will actually use the tool to
identify both the tasks and the ways they might best be accomplished.

There's a reason that many of the best products are designed by someone who
was building them for themselves as Customer#1 -- they internally knew what
was needed.

To extend the metaphor a bit - you're trying to design an improved hammer, but
how helpful would it be to consider the "Joe Carpenter" Persona and what he'd
want, vs talking to a bunch of live carpenters and finding that they really
have good hammers, but actually need better nail-pullers? The persona will get
you nowhere, but the actual carpenters will get you a new market and product
that sells.

~~~
juliushuijnk
The best persona's are based on interviewing real people, and I totally agree
that you need to keep doing those interviews to validate your design and when
the site/app/whatever is live.

it's not always possible to be your own target audience, for instance every
time you design something for someone who doesn't care about how technology
works :).

To add/stretch the metaphor; I get why (big investments in) personas can feel
like a waste of time, in the same way that you can waste a lot of time on
software architecture. It only makes sense if the team is going to use it. And
even then for simple projects it may be fair to say that common sense is good
enough. Still it can't hurt to invest 20 minutes in talking about the
architecture/personas just to be sure we're all somewhat on the same page.

~~~
toss1
Of course it's not possible to always be your own target audience, just an
ideal example. Yet your counterexample is also interesting. I'd say that you
need the best domain expert to design something for someone who doesn't care
how tech works. Obviously, this expert canNOT be one of those myopic tech-
centered geeks, but the essence of designing for non-tech users is to
understand the tasks & goals at a very deep level so that you can effectively
simplify the UI & process.

I'm all over architecture, as that can really simplify the dev, maint,
upgrade, sysadmin, & running processes.

But it'll take a lot more than these examples to convince me that personas are
useful for development.

I could be convinced that Personas are useful for marketing, but that's
because I don't know that much about marketing ;-)

~~~
juliushuijnk
So you get that best domain expert in the room with (part) of the team and
then the team needs to document the knowledge it has learned, to make it easy
to reason and discuss design choices for when the domain expert is not
around..

"I could be convinced that Personas are useful for marketing, but that's
because I don't know that much about marketing ;-)"

I guess the marketing people are right then. Everything is marketing :)

~~~
toss1
They should be documenting the actual _micro-detail_ of the tasks themselves,
what are the essential inputs & components of the tasks as well as the
signs/outputs/feedback that helps the user do it correctly and efficiently.

Zero of this detail has any significant or useful relationship with broad
characteristics of some abstract set of demographic characteristics,
motivations and attitudes.

The team should NOT be attempting to abstract the domain expert's knowledge
into some silly Persona, which will _lose_ all of the micro-detail about how
the person would actually perform the task. It'd be like trying to build a car
and talking about the paint color after you just interviewed the suspension
expert that told you about the key factors to the performance being how you
keep the tire in contact with the road at the proper angles and pressures.

If you are designing a hammer, it doesn't matter if the user is a small high-
school girl or an ex-Marine weighlifter, the characteristics you care about
are hand size and grip strength, and the range of sizes and types of nails
being driven. (The actual roles might be a small guy on the Asperger's
spectrum and a Woodsman competing woman -- the persona is irrelevant)

If your app is balancing a checkbook, it doesn't matter if it is a high-school
kid with their first account or a middle-aged worker -- the relevant data is
the key numbers on the screen, and the degree of background knowledge they
have which might influence what relevant data they want to see (e.g., novice
vs expert mode). The persona tells you zero about the skill set or assumptions
-- you need to know the detailed skill set.

Their age/sex/race/preferred clothing/music/etc. is utterly irrelevant.

I sincerely hope that you are not attempting to build tools of any sort,
because with the kind of garbage you promote as input, for the output, I don't
expect much...

~~~
juliushuijnk
"the characteristics you care about are hand size and grip strength"

"the degree of background knowledge they have which might influence what
relevant data they want to see (e.g., novice vs expert mode)"

If your research shows you that those are the relevant perspectives to take,
then you will base your personas on these main skill sets.

"Their age/sex/race/preferred clothing/music/etc. is utterly irrelevant."

You only include the qualities that make it a human being, so you can think of
this person as a human. So yes you need gender, age, race. If they are not
relevant to the task at hand, you can just take the average of your (expected)
user base, so no need to spend much time on that.

As for micro-details, you like to have a perfect list of all essential. In the
beginning of the process this is often not known. It's the job of the UX
designer to figure out what is essential. Sometimes it's obvious, sometimes
it's not.

"I sincerely hope that you are not attempting to build tools of any sort,
because with the kind of garbage you promote as input, for the output, I don't
expect much..."

How sincere.

My goal is not to promote my skills, but to explain how personas are used in
the UX process in practice to those who are curious about it. Let's say Jim,
31 year old back-end developer in Boston who want to move into front-end
development and is curious about how UI and UX comes about in practice.

Secondary personas is me. I'd like to learn what the thinking is behind the
negativity you see in some of these comments towards personas.

My current understanding that the negativity is based on a misunderstanding of
what UX design is (it's more than usability and UI design), and bad
experiences with personas in the past what wasted a lot of resources on
'irrelevant micro details'.

You seem quite passionate about providing a good user experience. Everybody
has the right to be grumpy every once in a while, so I sincerely hope you have
a nice day!

~~~
juliushuijnk
Can't reply to your comment, so I'll just say over here, thanks for clearing
that up.

"I sincerely hope that you are not attempting to build tools of any sort.."

First, don't insult people like that, it makes you look small minded.
Secondly; I'm working on a text command based ux tool :), you might just be my
target audience.

[https://www.trueuxapp.com](https://www.trueuxapp.com)

~~~
toss1
Fair enuf, mostly referring to the handicap you'd be working under w/those
abstractions. (should have written "not developing tools under that
handicap..." or similar)

Looks like a cool tool -- I'll check it out!

[edit: +descriptive parenthetical]

------
ravenstine
The article mostly suggests that personas are just done wrong, and that's why
they fail. Has this method ever actually been proven to increase success? In
my experience, they always end up being hideous stereotypes that nobody takes
seriously(for good reason).

------
ThomPete
Personas are primarily a mapping tool for providing the team with a library of
potential users, their background and needs with relation to your product and
to which the team can design up against. They fail (at being useful) because
they often have very little to do with the actual user's situations.

A better way IMO is to use customer support to figure out who your users
actually are or go and speak with your users and learn what they actually
want.

We never recommend doing them unless a project needs a lot of documentation
for a lot of switching hands and you are worried that some of the insights
might be lost on new team members.

As a design tool they aren't really that helpful for anything.

------
eurticket
Funny title that everyone reads and goes on with their comments. The article
was saying Personas in their current form fail. Mainly, because the companies
that design professionals use them for are not being utilized together with
the clients involvement. They aren't being translate throughout the entire
design process, they are for understanding design reasoning, instead of always
bringing up random things a customer may need, they are compacted into easy to
id personas, and that is what they are for. Simple recall, for clients and
designers to have a common vocabulary to talk about who we are solving
problems for.

------
natecavanaugh
In my opinion, personas fail because it's literally profiling, which has
limited use in identifying real world behavior.

Who you "are" doesn't define what you do, so I think the activity model works
better for UX work.

Instead of maximizing a product for "Jim" from Marketing, optimize for what
Jim needs to do and get done. Everything else is some sort of weird bias.

------
anthonyshort
I feel like I need to point out that in my experience demographic personas
like this aren't used by product designers. I've seen marketing use them. Not
designers.

Designers often get associated with fluffy exercises so I want to kill that
stereotype. I don't think I've ever worked on a product team that used
demographic personas like these.

------
mirimir
Not what I was expecting. I love my personas. Most of them, anyway. Especially
Mirimir. Some of them are not so nice. But hey.

------
djklanac
Why not create profiles of real customer contacts? Use their own words for how
they describe themselves and their goals.

~~~
TheOtherHobbes
That would require real effort instead of storytelling during work hours.

Whoch is harsh, but that’s the point. You are going to get far more insight
from real customers than you are from one relatively homogenous sub-
department’s imaginary beliefs about who your customers might be.

IMO the latter is pretty much the definition of one of David Graeber’s
bullshit jobs.

[http://evonomics.com/why-capitalism-creates-pointless-
jobs-d...](http://evonomics.com/why-capitalism-creates-pointless-jobs-david-
graeber/)

~~~
megaman22
There's nothing more valuable than watching customers actually use a product.
Almost never will they do it the way you expect, and absolutely never will
they want to do it the way that the designer intended. Nothing points out a
painful, complicated, broken, confusing UI as quickly.

------
perseusprime11
Here's an interesting counter point:
[https://www.nngroup.com/articles/personas-jobs-be-
done/](https://www.nngroup.com/articles/personas-jobs-be-done/)

------
_pmf_
At best, it's something that arises organically from requirement elicitation
without involving a UX team.

At worst, it's completely off the mark.

