Why Personas Fail

The other problem with Personas being the deliverable is often they're a form of making the marketing person's personal preferences look like user research. So instead of testing what thirtysomething professional males actually respond to, the campaign gets designed around imaginary Alan's enthusiasm for active lifestyles.

(In an extreme example of this, "Stefan" who was conceived by an internal marketing team to illustrate how a certain niche used a certain industry website ended up as an actual marionette with social media profiles with 2000 followers, blog articles about his holidays and photos taken with some very bemused industry executives who were also encouraged to download Foursquare so they could check in with him at tradeshows. An awful lot of paying customers' actual needs got ignored at the same time as the marketing team were having fun turning a persona they'd conceived into a mascot though)

I find this comment really funny because "satisfy your hunger" is the primary marketing message that Mars pushes for Snickers.

So in the course of questioning the value of a marketing concept (personae), Alan is inadvertently demonstrating that he has fully internalized the Snickers marketing.

Maybe this was intentional? If you have a link for greater context, I'd be interested to see it.

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

if one were to read the motivating factors behind personas as described in “the inmates are running the asylum”, one would never come up with A. If one were to follow agile in principle (do; evaluate; improve what hurts; repeat), one would not end up with capital-A Agile Industry prescribing process by the book.

This sounds like the same reason people avoided C++: after seeing lots of unnecessary complex C++ just for the sake of being “object-oriented” but entirely missing the point, who’d think it’s possible to write clearer code in C++?

> My other insight was that many UX firms treat artifacts like Personas as the deliverable.

This matches my (limited, anecdotal) experience. They can be used to demonstrate that a set of UX choices will result in a set of results, but don't by themselves say if those results are better than alternatives unless the alternatives are also run through the same test. Essentially they act as benchmarks. Benchmarks are not a good deliverable and have little value if you benchmark only a single option.

Personas give you a context for what A would do when B. It's that decision by A that's valuable for the business.

I thought it was broadly understood that personas were just for slide decks.

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.

Yes, the very idea that customers can be bucketed is flawed. We are all unique people.

But we do not categorize our customers into buckets because we are denying their individuality. We do it because we lack the cognitive firepower to address several thousand people individually, by multiple orders of magnitude. Categorization isn't a denial of their humanity, it's an acknowledgement of our humanity, as opposed to being some sort of post-Singularity AI or Deity that is capable of individually addressing people. We have no options to address this flaw.

Pretending that we've just got one user who wants to routinely buy Depends, yet at others for no apparent reason, is intensely into punk rock, and on another day forgets how to speak English and is only going to interact with your site in Tagalog, is just going to distort your UI in other ways. I don't think acknowledging people's individuality is accomplished by only acknowledging one individual, with that individual constructed in such a way that this one individual is representative of nobody.

  it would make more sense to have
  just one typical user,

Some products have users with distinct - almost contradictory - requirements.

For example, some spreadsheet users want simple graphs with big numbers that will look good in presentations, and a simple UI they can use on their phone. Other spreadsheet users want to make complex graphs with labelled arrows, thousands of points, multiple different graphs with aligned axes, and things like that.

Multiple personas can be useful for expressing that fact - otherwise you're stuck saying the just-one-user wants things to be simple and complicated at the same time.

I disagree. Where website have a variety of different potential types of user, it can be useful to explicitly describe those different types of users, their needs and goals. Calling them Bob or Mary, can just be useful shorthand and avoid segments getting forgotten about.

In speccing and QA, I've always included a section on 'Works for Mary? Works for Bob?' etc. It's not rocket science and shouldn't be stupidly glossy in my opinion. But initial agreement can really help functional design.

I disagree. The concept of personas is useful for abstracting the user's previous experiences and habits formed, not their current goals. It's a useful abstraction that should be considered an abstraction and not a concrete example. When discussing 'stay at home moms', we're encapsulating the past experiences of such personas.

I think for some products this would actually be useful. Some products are inherently not exactly goal-oriented - Point A to Point B.

Take Facebook for example. It's not about achieving the objective of putting photos online, it's about the mystery of being invited to a website to share who you are with your friends and learning how you can interact through this new medium. It really mattered that Facebook targeted a specific demographic. If they didn't target that demographic exclusively, they wouldn't have succeeded, because college student's mom's would have been on there and they would have felt vulnerable, and found somewhere else to share.

Persona as a "mascot" for a scenario has been helpful for me. It helps to think through the idea from the user's point of view, not how the software wants to be written, so to speak. Having two personas for a scenario also helps to delineate a spectrum (i.e. a casual and pro user) when you're going to have users with different requirements going through the life cycle of your product.

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.

Dell is guilty of this sort of thing. Trying to price compare between “business” and “home” computers is a nightmare.

Did I want the "Datacentre" or the "Agile Datacentre"? Fucked if I know, all I know is that my servers aren't responding and your phone tree is fucking confusing.

I think there is a disconnect between what people think personae are for (improving usability for everybody) vs. what they are actually for (focusing resources on the few most important market segments). Focusing means that usability may actually go down for people who don't fit into those segments.

And of course like anything else, even if personae are conceptually sound, a company can still screw up in the execution.

Because they're selling outcomes, not features.

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.

That's my understanding too. The useful way to do a persona is:

1. Find a (real!) user of your product, that you believe to be more-or-less an "archetype" of a class of similar users

2. Start writing down his(her) workflows/ how (s)he uses your app/what (s)he's trying to achieve, etc.

AFAIK my company is even preserving the real first name of the "persona". If we're talking about real people, then it makes sense to use their behaviors/needs to guide the design of the product. If we're talking about imaginary people... well, you're just optimizing your product for some imaginary user :)

"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.

This seems like the right answer- I wish it was higher in the thread. Do you have a reliable reference? As I said in another thread I'd really like to see examples of insights that were arrived at due to the use of personas- at least where personas made getting that insight more efficient.

Exactly!

I find that a lot of people like to sit down and play "let's pretend" instead of doing real work.

Personas come across as an easy way to get sidetracked by a game of "let's pretend." That's when personas are just stereotypes.

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.

It still makes sense to remind, that UX processes are not exception here. Failures of classical software engineering may feel distant and even not applicable to an agile team focused on UX, so some good explanations on why this also happens in the UX domain, and maybe even as a part of their process, are helpful.

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.

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.)

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.

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...

It may make sense, when you have 10 users, but then you can just skip profiling (and, by the way, profiling real users, at least in EU, is strictly limited from legal perspective - it just doesn't worth it). When there are thousands of users, real customer contacts may create unnecessary bias. There's no "average" real person, which means that serving the needs of one real person, you may hurt others too much. Personas are synthetic profiles for a reason: they cover the whole audience of the project or feature.