Personas are basically representations of our research distilled into patterns of likeness that then have a narrative of realness wrapped around the data. It becomes a picture of a real person we can point to and say “Dave over there, he needs this kind of experience.” They are incredibly useful for aligning around real human needs, and showing the differences that can exist in users.

For example, an ecommerce site like Best Buy may have personas that identify attributes of two groups of users in their computer department:

  • A tech power user who understands the details, has money to spare, upgrades on release cycles, and skews heavily young and male. They want every test stat available, and if you try to give them advice they believe they know more than the expert.
  • A parent who shops for a child, doesn’t know what the technical terms mean, are on a budget because they are worried the kid might lose the item, and skews middle-aged. They like things spelled out in clear language, and preferably want an expert to help.

This might indicate to the product and design team that there is an opportunity to present computers in a straightforward and easy to understand way, with a buying wizard and reviews, while adding the ability to deep dive into tech details. Categories of computer might be named to indicate “good for kids” or “entry level” and also “pro gaming” or “professional grade.” Promotions may target back to school time, but also may align with E3’s yearly conference where they may upsell GPUs.

This is great information to have, and being able to point to those personas is a powerful tool when aligning stakeholders and getting buy-in to prioritize a decision.

Wait a minute though, how did we get all the customers down to two patterns? That can’t possibly be the complete story…?

The problem with personas

There are some logical issues we’ll run into when looking at personas that are sometimes washed over and hidden in the spirit of getting to good enough. The problem is that personas can’t be good enough, they need to be accurate – or they are actively BAD.

Where data doesn’t exist, people will make data

The internet is full of guides on how to create personas, and even ways to create personas when you don’t know the data. Proto-personas are a tool that is used to make up a profile of a person just by asking the team what they think the user is! This can be an echo chamber for the team’s incorrect assumptions.

When pointing to a person, it’s hard to disagree

When creating personas, people will typically give the person a name and a photo. Over time, the mythology of this “Rebecca Personaname” with a recognizable face can lead people to think of her as a real person, an actual member or user. Decisions can be made by asking what Rebecca would want. But if Rebecca never existed, are we actually building things people need? Are we solving real problems, or just those that appeared in this grouping of data? Is this data even accurate anymore? Was it accurate to begin with? Maybe we’ve always been designing for Rebecca’s problems, and that’s why we’re in this boat…

But to understand our users we need to start somewhere, right?

So what should we do in absence of a powerful and accurate persona? Well a real persona in the cases of our members is a valuable tool that would have a strong impact on making the right decisions for various types of members with different needs. So the right place to be is where good, valid personas can exist, and for that to happen we need to:

Best: Do the research and create useful personas

Proper, valid personas require a deep understanding of the wide range of our users, and include demographic segmentation, psychographic attributes, qualitative stories, shared attitudes, goals, pain points, and expectations. This requires time working with data, creating our methodology, running the study, synthesizing, and finally writing the personas.

But in absence of that research and persona development process, we can still anchor on who we’re designing for and what their core needs are by looking at:

Good: User Profiles

Inside Oscar we had the benefit of users who were performing jobs. Much of their job is scripted into a process workflow, and they know exactly how to get from point A to Z. We don’t need to know that a claims processor keeps chickens, or that they stop at Starbucks every morning before work.

In this case, we can build what are essentially archetypes without quirky names like “the activator” or “the procrastinator.” We can name an archetype “Claims Processor” or “Broker” and include the research observations that are common among the roles. We can include job details like title, the platforms they use, the tasks they perform, and their motivations and incentives. These are now looking close to personas, but without the fiction that is layered on when we try to name and put a face to these personas.

Even for members we can use general understanding alongside demographic segmentation to get a sense of who we’re working with, their motivations, pain points, and needs.

Then to put profiles into action

Often personas are used to talk about how a user might go about solving a problem, or taking on a job to be done, but they don’t actually contain that information. Really they are just a jumping off point for us to make up a story. Scenarios can tell the real story of a user through research-observed patterns, in a descriptive way that makes the journey feel real. These work without ever really worrying about the personal parts of a persona, and use just the tangible impact moments.

So combining just enough pattern matching about our users with stories about their real, researched experiences can give us a solid picture of those users without investing in deep research to develop personas.