"Death to Personas" started as a joke title. Then I realized maybe I wasn't joking.

User Personas show up in every UX book, every course, every "intro to product design" deck you'll ever encounter. They've become such an accepted part of the field that most of us forgot why we started making them in the first place, or what they were supposed to do for us.

Where Did Personas Come From?

Hard to believe now, but there was a time before software existed. Not really, anyway — not the way we think of it today.

For roughly 40 years, developers built things to see if they could, or for other developers to use. Then, in the 1980s, commercially viable software arrived for non-developers. Enter Alan Cooper.

Cooper is the originator of Visual Basic, which he sold to Microsoft in 1988. He went on to freelance as a designer and developer before founding his own consultancy, Cooper, in 1992.

Cooper believed the developers of his time weren't centering user needs. They built for themselves, and if other people found it useful, that was a bonus.

As software commercialized, a wave of products emerged that only developers really knew how to use. Adoption moved slowly because most people weren't developers.

So when Cooper worked on his own projects, he interviewed the people who'd use them. He got to know them well enough that he'd pretend to be them while making decisions. There's a story of him creating "Cathy" — either a real interviewee or a composite — and holding conversations with her as he worked.

When Cooper moved from hands-on development into consulting, he formalized the method. It stopped being a private thinking tool and became an artifact: something that could communicate research and user empathy to a whole team, not just one person's head.

Cooper was doing this in the early-to-mid 1990s. We're now in 2026, and a lot has happened with computers.

In 1984, Apple released the first Macintosh, the first commercially viable personal computer with a graphical interface. In 1989, cognitive scientist Don Norman published "The Design of Everyday Things" — which every UX designer has pretended to read at least once.

In 1990, the first version of Microsoft Word for Windows arrived. They haven't improved it since.

In 1991, Photoshop launched and design started its shift from print to digital. In 1995, Norman coined the term "user experience design." In 1997, Steve Jobs resurrected Apple with the iMac and rewrote industrial design for computers. Then he put computers in our pockets with the iPod in 2001, and the internet in our pockets with the iPhone in 2007.

The way we interact with technology today bears almost no resemblance to the 1990s. So the question is fair: Are user personas still doing what Cooper built them to do?

Why Should Personas Die?

Cooper was onto something real. And then the world changed underneath the tool he built.

Here's the difference that matters.

We are all users.

We use software, apps, kiosks, interfaces, constantly. We could sketch Instagram or Spotify from memory. Personas were built to create empathy for people whose experience with technology was foreign to us. That gap barely exists anymore. Our parents, our grandparents, our kids — they've all got deep experience with technology now, too.

There's a second half to this, though. While we're all users, we are not our users. We build things for people who aren't us. That takes a mix of empathy and objectivity, held at the same time.

So if empathy is still the goal, why are personas the wrong tool to get there?

Here's how it's supposed to work. You identify your users, go talk to them about their real experiences solving real problems, then synthesize what you learn into one or more composite people. The composite exists because not everyone on the team can go do the interviews themselves.

The problem is that research takes time. Finding users is hard enough — then there's the protocol, the interviews, the synthesis, the persona itself. So a lot of teams skip the hard part and jump straight to inventing people.

But even a strict rule requiring research first wouldn't fix this. I'd still want personas gone.

Even done well, personas are representative averages — the most common denominators of a group.

If most users are male, 18 to 34 and on mobile, what happens to the users who are none of those things? Are we not designing for them? What about the user who's male, 25, on mobile, and has a motor disability? Where does he fit?

We call the leftover group "edge cases." And edge cases go to die at the bottom of the backlog.

Some teams swing the other way and build hyper-specific personas instead — closer to a marketing profile than a design tool. Useful, maybe, for content strategy or ad targeting. Less useful for building the actual product. You get a wealth of detail about one imagined person and not much clarity on what to do with it.

Generalize too far and you exclude everyone outside the average. Get too specific and you exclude everyone outside that one person. Either way, most of your users end up standing outside the frame.

So if we're serious about building empathy, a few questions are worth sitting with:

• How many digital products actually need to be gender-specific?
• How are we accounting for a full spectrum of ability?
• In a world built on responsive design, does specifying devices really matter?
• Is demography destiny, or can we separate what people do from the stats on their baseball card?

What Should You Do Instead?

Talk to people.

Talk to them early and often. But don't ask what they want — what people want and what people need are rarely the same thing. People will tell you what they want. Most of the time, they don't know what they need.

So how do you know what to actually ask them about?

I like to run an assumption-mapping exercise before writing any research protocol, solo or with a group. Build a two-by-two: least important to most important on one axis, hardest to easiest to validate on the other.

Say you're designing an experience where people upload selfies and the product turns them into art. What are you assuming about the people who'll use it?

You're assuming they like art, or at least like the idea of becoming art. You're assuming they take selfies. And most critically, you're assuming they'll actually upload one — because if they don't, nothing else about the product matters. Those three assumptions are important and easy to validate, so they land in the top-priority quadrant.

You might also assume they'll want to share results outside the product. Probably true, but not validating it doesn't break anything — easy to validate, lower stakes. You might assume they'll tell their friends. Harder to test, and not core to whether the thing works — low priority, low ease.

Maybe the museum sees this as a future revenue stream. You can ask people if they'd pay for something a hundred times and learn nothing, because intent isn't the same as a wallet coming out. That assumption might be the most important one on the board, and you won't know it's true until there's something to actually buy.

Go validate those assumptions with real people, and you learn more than who they are. You learn how they'll engage with what you're building.

The "how" has become more important than the "who."

Most of the time, when someone engages with a digital product, they're trying to accomplish something. Book a flight. Buy a toaster. Reach a friend. Share a moment. If we can name the primary action, we can define the mindset behind it — and the useful thing about mindsets is that anyone can have one.

Someone passively watching has a different mindset than someone actively searching. Someone playing has a different mindset than someone buying a vacuum. Our job is making it easier, simpler or more engaging for someone to reach whatever goal they walked in with.

Say we're building something to help someone learn a new skill. Here's what actually matters:

• Is this a primary action?
• How long does it take?
• How many steps are in the process?
• Are the steps logical?
• Are there distractions along the way?
• How satisfying is the end result?
• Is the process repeatable?
• Can it be completed in one sitting?

Here's what doesn't:

• Gender
• Age
• Physical or cognitive ability
• Device type
• Location
• Education
• Income
• Marital status
• Hobbies or interests
• Brand affiliations

We shouldn't care whether someone's on an iPad. It should work, and it should be great, no matter what.

Back to Cooper. I found a photo of him from an article he wrote titled something close to "Why People Hate Personas." His thesis lands close to mine. He built personas because he wanted products that were human-centered, ones that delivered real value and satisfaction. Whether you keep making personas or not, you can't build for people without understanding them.

It was never about the tool. It's about staying as curious about your users as the world keeps forcing you to be.