Death to Personas: A Mindset-Focused Approach to Designing Inclusive Web Experiences

I came up with the title “Death to Personas” as kind of a joke. Come up with a hot take first, figure out the substance later. But the more I thought about the idea, the more I realized that it wasn’t just a funny line. I had a real opportunity to address something about the field of product design and development that has been bugging me for a while.

If you open a book about user experience or take a course online or read an article about it, you get introduced to the concept of User Personas pretty early on. And they generally look like this.

This is me in user persona form. So — what can we learn about me as a user persona. I have a master’s degree, I have a smartphone and a laptop but not a tablet, I have strong feelings about the user experience of (HBO) Max.

What does this tell you about my decision making process? Or how I want to access information?

Now, I recognize that this is biased. You probably shouldn’t make a user persona for yourself but my issue with user personas is that they have become such an accepted part of user experience design that we kind of forgot why we started doing them in the first place and what they were supposed to help us do.

Where Did Personas Come From?

I know this is hard to believe but once upon a time, there was no such thing as software.

What we think of as software now wasn’t really a thing until really the early 80s. So for roughly 40 years of software development, developers were building things either to see if they could or for other developers to use. Then in the 1980s, all of a sudden we had commercially viable software that was created for non-developers to use.

Enter Alan Cooper.

Alan Cooper is the originator of Visual BASIC, which he sold to Microsoft in 1988. He then became a very sought after freelance designer/developer until he founded his own design consultancy in 1992 called Cooper.

Alan Cooper believed that the software developers of time were not centering the needs of users when developing their products. They were basically building stuff for themselves and if other people used it, that was cool, too.

As software development became more commercialized and software use became more commonplace, there were a bunch of new products that basically only developers knew how to use. This made software adoption move pretty slowly because not everyone was a developer.

When Cooper worked on his own software projects in the 80s and 90s, he interviewed the intended users of the product and got to know them and their needs so well that he would pretend to be them while he was working.

There is a story of Cooper creating the character of “Cathy” who was either a real person he interviewed or a composite and then having conversations with her as he made product decisions.

When Cooper transitioned from hands on development to consulting, he realized that there was a real need for this methodology so he formalized the concept and made it less about talking to yourself while writing code and more about creating an artifact that could be used to communicate the value of both research and user-empathy to other people working on projects or stakeholders.

Cooper was doing this in the early to mid-1990s. We’re now in 2023 and I don’t know if you’ve heard but a lot has happened with computers.

I made this not remotely academic timeline because not only has a lot of stuff happened, a lot of stuff has happened in a relatively compressed amount of time.

In 1984, Apple released the first Macintosh, which was the first commercially viable personal computer with a graphical user interface. In 1989, a guy named Don Norman, a cognitive scientist who worked at Apple, published a book called “Design of Everyday Things” — which every user experience designer has pretended to read.

In 1990, the first version of Microsoft Word for Windows was released and the interesting thing is that they have not made any improvements to it since then.

In 1991, the first version of Photoshop arrived and the field of graphic design started to shift from the world of print to the world of digital interfaces and interaction. In 1995 — Don Norman came up with the name “user experience design” to describe what people were doing when they created these new digital experiences.

In 1997, Steve Jobs resurrected Apple with the iMac and completely changed industrial design for computers. Then he put computers in everyone’s pocket with the iPod in 2001 and the internet in everyone’s pockets with the first iPhone in 2007.

Aside from being forced to use Microsoft Word sometimes, the way we interact with technology today is very different than it was in the 1990s. So are user personas as useful as they were when Alan Cooper developed them?

Why Should Personas Die?

Alan Cooper was absolutely onto something when he created user personas as personal computers and commercial software entered daily life. And then the entire world went through a paradigm shift in how we did pretty much everything.

So why do I think User Personas should die?

There is one very significant difference in the way we approach designing and building things today that just wasn’t true in the 80s and most of the 90s.

We are all users.

We all use software, we use websites, we use native apps, we use digital kiosks, we interact with technology constantly. We have experience with established interaction patterns, we could probably draw the interfaces for things like Instagram and Spotify from memory.

User personas were fundamentally about building empathy for people whose experiences interacting with technology were very different from our own. And to a large extent, that is no longer the case. Our parents, our grandparents, our children — all have pretty deep experience with technology.

There is a second part to this thought, though. And that is, while we are all users, we are not our users. We are creating things that are generally intended for people who are not us. We have to approach creating them with a mixture of empathy and objectivity.

So if we are still trying to develop empathy, why are user personas the wrong way to do it?

The process for creating user personas should be that you identify who your users are or who you assume them to be, you go out into the real world and you talk to them about their actual, human experiences engaging with technology to solve a particular problem.

Then you take all of the data points you gather from talking to people and synthesize them into one or more composite people. You create those composite because not everyone on your team can go out and actually talk to people. So you have to create personas that are comprehensive enough to give the team a better sense of who you talked to and what you learned.

The problem is that research is time consuming and sometimes it’s hard enough to find your users, let alone to book time with them, write a research protocol, conduct an interview or observation session, synthesize the results and then create user personas.

A lot of teams have skipped the hard part and jumped straight to making fake people.

But even if we had some kind of universal mandate that you couldn’t make user personas if you didn’t do user research, would that solve the problem? No, I’d still want them to die.

Even on their best days, user personas are representative averages, focusing on the most common denominators of a group.

If most users identify as male, are between the ages of 18–34 and are using a mobile device — what about the users who are none of those things? Are we not designing for them?

What about a user who identifies as male, is 25, is using a mobile device but has a motor disability? How are we accounting for that user’s needs?

We end up lumping all of the “non-most” users into the category of edge cases and we all know that edge cases go to die at the bottom of the backlog.

On the flip side, some teams create hyper-specific personas with information not just on frustrations and motivators but very granular details on demographics, household income, names and ages of children, brand affiliations, and on and on.

These are more like marketing personas that may be helpful for content strategy or ad buys but are less useful for creating web or app experiences. You get a lot of details about a real or imagined person but at the end of the day, how are we using this information?

In the same way that generalizing our users into “most common” limits our ability to see people outside of wide margins, when we create these hyper-specific user personas, we now have super narrow margins and everyone else is sitting outside.

Creating user personas in the traditional format has forced us to make some weird and kind of limiting decisions about the people we’re building for. So if what we’re trying to do is build empathy and understanding for our users, I think we need to consider –

• How many digital products need to be gender-specific?
• How are we accounting for a spectrum of abilities?
• In a world of responsive design, does specifying devices really matter?
• Is demography destiny or can we separate the things we do from the stats that might appear on a baseball card?

What should you do instead?

Talk to people.

Talk to them early and often but don’t ask them what they want. What people want and what people need are often two very different things. People will tell you what they want but they mostly don’t know what they need.

How do you know what to talk to people about?

Sometimes it can be hard to write a research protocol. Especially if you’re creating something new. So I like to do an assumption mapping exercise to frame up what questions you need to have answered.

You can do an assumption mapping exercise yourself or with a group. I highly recommend the group version but solo works, too.

To do it, you create a 2 by 2 matrix with the least important to most important and most difficult to least difficult to validate. Importance is literally how important the assumption is for the thing we’re building and the difficulty level is how hard it would be to actually validate our assumption.

Let’s say you’re designing a digital experience for an art museum where people upload selfies and you turn them into art. What are some assumptions you have about the people you’re creating this experience for?

First, we assume that these people like art or that they like the idea of themselves turning into art. Then, we assume that they take selfies. And probably most importantly, we assume that they’ll upload selfies to the site. Because if they don’t do that, the product doesn’t work at all.

These three things are really imperative for us to learn to know if our product is going to be successful and pretty easy to find out, so they are in the easiest to validate and most important quadrant.

We might assume that these people would also be interested in sharing their results outside of the product. That’s probably true but not validating it doesn’t really have much impact on whether they’ll use the product overall. So we mark that as easy to validate but less important.

We might also assume that these people would tell their friends about the product. And we can ask about that but it’s not core to what we’re making and until it actually happens, we can’t really validate it — so that’s less important and difficult to validate.

Maybe we’re making this product for an art museum but they think it could be a potential revenue stream. It doesn’t really matter how many times you ask someone if they would buy something, because until they’re actually in a position to buy — you can’t know if they will. So this might be the most important assumption if we’re thinking about this as a money maker but we can’t validate it until we actually have a product you can pay for.

If we go out and validate those assumptions by talking to potential users, we’re going to end up with not just insights about who these people are but how they might engage with the product that we’re building for them.

That “How”, in my opinion, has become more important than the “Who”.

For the most part — when users are engaging with a digital product, they are trying to accomplish something. They might be trying to find a flight, or buy a toaster, to connect with a friend, to share their experience.

If we can identify what we think these primary actions are, we can define a user mindset for them and the cool thing about mindsets is that anyone can have them.

The mindset for someone who is passively watching something is very different from the mindset of someone who is actively searching for something. The mindset of someone who is playing a game is different from the mindset of someone buying a vacuum cleaner.

Our design and development decisions are about making it easier, simpler or more engaging for a user to reach their goals, whatever those goals may be.

If we’re building an experience to support learning a new skill, what are the things that we need to think about?

Things that Matter:

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

Things that Don’t:

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

And we don’t really care about their gender, their age, their abilities or whether they’re on an iPad — it should work and be awesome, no matter what.

So back to Alan Cooper. He created personas because he wanted the products that he made to be human centered and to deliver the most value and satisfaction to users. At the end of the day, whether you continue to create user personas or not, you can’t create products for people without trying to understand the people you create those products for.

It’s not ultimately about the tool. It’s about an intentional, thoughtful and empathetic process that evolves as people and technology do.

Death to Personas was presented at DrupalCon 2023 in Pittsburgh, PA.

Elliott Mower is Head of Product at Mediacurrent. He is working on a presentation about how much he dislikes the typeface Raleway.