Your personas probably suck. Here’s how you can build them better.
Personas. Maybe you love them. Maybe you hate them. Either way, you’ve probably concluded at some point in your career that your current personas are failing you.
It’s pretty much accepted that the concept of personas is a key tool in a user researcher’s professional tool kit. UX researchers have done such a good job of embedding the idea that empathy-building is critical to developing a successful product, that stakeholders cry out for another persona-driven deliverable.
So why do you feel like the skill of creating valuable personas; personas that actually resonate with the users we know, love, and advocate for, is a dark art that you can’t conquer. Why has the tool of personas transitioned from being the go-to output to a concept that ruffles the feathers of most UX Researchers?
What’s killed personas?
Personas have become plug and play templates
As a profession, we have slept walked into the habit of creating personas that are templates. They all look and feel the same. Let us be clear, there is nothing wrong with a template. The problem comes when people use it as the endpoint instead of the starting point.
Personas are too specific but not useful
Creating content that is ultra-specific to populate your personas cards, feels useful, it may even feel like the thing you must do. It's not. Placing, ultra-specific content like salaries or photographs next to important content like attitudes and approaches is damaging to the goal you want to achieve. It tells the reader, this person can only share the attitudes and interests only exists if the user looks exactly like this photograph or earns this amount. That is simply not true.
Personas are built from pre-existing research
Researchers are rarely given the time and space to build personas what they set out to do; build a holistic understanding of users in your product space. Instead, we try and squeeze personas out of existing research we already have done, or worse still build them off ideas we have about who our users are. This won’t work. You can’t build personas from pre-existing research that was not conducted for the purpose of building researchers. So don’t do it.
Personas are creating stereotypes, not archetypes
Deep down, all UX researchers know these three things but it can be hard to shake a bad habit and that's how we end up with personas like these.
Legalease Leonard, Rachel, Pete, Brad, and Jennifer are not accurate pictures of our user groups. They are not accurate pictures of anyone’s user groups! They are shortcuts that put our users in boxes, they oversimplify the complexity of individuals and they are not useful.
As UX researchers, we a letting a critical tool in our toolkit be used badly. That leads to poor design decisions and that leaves our colleagues with a poor reflection of our offering. That’s a big problem for us as a UX community but it was becoming a damaging problem for us because our users are already one of the most stereotyped groups on the planet.
Why did we take on the task of resuscitating personas?
Our users are prisoners. I work as a senior user researcher at the Ministry of Justice, in the United Kingdom. Whenever a member of the public interacts with the services or policies of the Ministry of Justice they are probably going through some of the worst moments of their lives: imprisonment, divorce, power of attorney, or a court case.
But in particular, the work I have been doing focuses solely on prisoners. The staff that they work with to build products and services for this user group, cannot meet their users. They are physically locked behind bars, out of sight and mind. This means they often build products and services for people they will never meet but that could impact the course of a prisoner's life forever. That’s a lot of responsibility.
If that wasn’t enough, stereotypes about prisoners are reinforced daily by the media, in the tabloids, and in shows like Prison Break and Orange Is the New Black.
This left myself and my peers Carol Pizatto, Faye Mitchell and Lindsey Martin— who are also part of the UX Research and Design community in the Ministry of Justice — in a pretty dire position.
We had to help our colleagues build services with empathy and understanding, for a user group they will never meet, whilst challenging long embedded media and societal stereotypes, all with a tool that sucks.
We weren’t left with much of a choice. We needed personas to work, so we started from scratch to address the skeleton in the cupboard that is personas. We did the hard work, so you don’t have to!
How to revive the tool of personas
We asked ourselves what would good personas actually look like? And what a question that turned out to be.
First, we turned to academia. They have been doing personas right for decades, they even have a who field dedicated to it, it’s called qualitative data analysis and there is a lot of good practice we can borrow and build on. I went to the University of Oxford, so we went back and got in touch with some professors. They reminded us to be systematic about collecting our data and to apply rigorous consistent principles when analysing it.
Next, we explored anatomy, folklore, and mythology and checked how archetypes were built in those worlds. This deeply inspired the design phase as you will see later.
Finally, we looked at plays, museums and books to better understand storytelling and learn how to curate the complexity and depth of people’s lives.
Using all of this research, we took a long hard look at that template and we came up with a seismic shift.
Good personas don’t have heuristic shortcuts that drive biases. The time has come for personas with:
- No ages
- No photographs
- No salaries
- No names
- No genders
This may be quite shocking to a lot of people. It’s rare to see personas like this, and you might be thinking if I don’t have any of that, what am I going to put on my personas!?
We want you to:
- Focus on your users as people, not what defines them in a census.
- Allow the depth of data and richness of insights to flourish. Humans are complex.
- Stop letting people judge your personas by their cover, strip out looks and personification.
Don’t panic, we’ve got a five-step framework to help you figure out how to do just this.
A five-step framework
In summary, the five steps that we will walk you through are:
- Ask rich questions, not dumb questions
- Write a codebook
- Code your data
- Map your data
- Form your personas
Before you get started
Before you start on the road to good personas, disregard any existing data you already have. Don’t be tempted to borrow from it, we have no doubt it was great research that might well feel appropriate but it was collected for other purposes. Start from fresh! Your personas will emerge from the data you collect and you can’t do that recycling existing evidence.
What we are proposing might feel overwhelming but you can do it with very little time and a small team. We did it one day a week over 10 months alongside our other project work, using tools you probably already know!
The tools you will need
We used these tools, but you can use whatever you have access to that has similar functionality:
- Notion: A wiki tool for documenting and recording the project
- Dovetail: A synthesis tool for analyzing, tagging and storing our data
- Miro: A collaborative whiteboard for analysis and affinity sorting
- Google Sheets: A data processor to find patterns in our data.
Step 1: Ask rich questions, not dumb questions
Your users don’t exist in a vacuum of your product and only your product. Their approach to your product is driven by events in their wider lives but also bigger, more holistic ideas like wants, wishes, stresses, and attitudes.
Stop asking people just about your product, start asking people about themselves.
Take these questions up here. When we set out to interview prisoners we could have asked the obvious questions like:
What’s is it like to be locked up? What do you miss?
We might have got some good data but its more likely we would have got circumstantial, specific evidence, which we know isn’t useful. In fact, most of the time, we could have learned from simply observing the environment they occupy. The point of asking rich questions is to unearth the data that is not so obvious or observable but is fundamentally shaped by the environments people occupy. So, instead, we asked them questions like this,
What are you most proud of? What does a good day here look like?
These questions are not looking to understand the surface level. These questions tackled family, staying healthy, setting goals, equality, and a fair justice system. Ideas and topics that matter to all of us, but which are experienced very differently in a prison environment. For our users, in particular, this approach was surprising and refreshing, prisoners rarely get the chance to talk about themselves just as ‘themselves’
Questions like this are called rich questions. In order to gather the evidence we needed to design a set of personas, we temporarily took off our product research hats and had a conversation. Sure, that conversation was guided around topics we as a business are interested in but it was not a set of rigid questions like a questionnaire.
This approach is so important because rather than imposing what you want to talk about, it lets users showcase what they think is important to them as individuals. And if you know what’s important to individuals, you can design services and products that meet speak to those users directly.
It can take a while to craft these questions. It can feel hard and challenging, you might even need to test drive some of your questions. You will know when you have got there when it feels less like an interview and more like a really insightful and rich conversation.
The key aim here is to get to the heart of what matters to your users, not your product. If you understand your users, you can drive the development of a successful product.
So there you have it. Step one: identify your users, collect your data but make sure you ask rich questions not dumb questions.
Step 2: Write a codebook
First things first, do some housekeeping. Get your data in order. Get it into a position to be analysed. If you were able to record the interviews, you should transcribe them verbatim. Put somewhere you can easily access. We used Dovetail for this.
Only then, can you sit down and write a codebook.
What is a codebook, I hear you cry. A codebook is something that academics in this field use all the time. Put simply, a codebook is a map to help you analyse your data.
The codebook, on the whole, tends to write itself but this is how you go about making one. It's a simple sequence.
- Read through your data carefully. As you read through your data, you will start to see themes emerging.
- Once these themes emerge a handful of times you label it. This theme then becomes what we call a code.
- As you write the name of the code down, in your codebook you should give a description of what that code is about. You should also give an example from your data. Then finally you should give an example of close but not quite. This will stop your coders from misinterpreting important nuances.
Repeat this process as you read through your data a couple of times. You might only have a handful of initial codes, perhaps five or maybe ten. That’s okay because these codes will change and evolve as you analyse the data more critically. In our case, these definitions were continuously challenged by each other and iterated as we became more familiar with the data.
You can learn more about the process of coding and how to write a codebook by reading this book Qualitative Data Analysis by Saldana.
Step 3: Code your Data
Print that codebook. Have it easily to hand. We kept ours in Notion and projected it onto a big screen and gave people print outs.
For this step, you will need to put your transcripts into a tool like Dovetail that lets you attribute tags to the data.
You should work in pairs to analyse the data, this improves what we call inter-coder reliability and makes sure your inherent bias is not creeping in. It sounds complicated but all it means is that you sit together and work through the transcript line by line and attribute codes from your codebook. If there isn’t a code in your codebook and you think the data is important enough you should make one. These codes might change over time as you go through the process.
That’s okay, let the data tell you what is going on. Don’t tell the data what’s going on.
What is important here is to take your time. This is the longest part of the process. You will need to read each line carefully. No line should go untagged! Even questions and chit-chat.
After you have coded all of your data it might be possible to start grouping your code into tiers. For example, we have the thematic code of ‘relationships before prison’ was the sub-code of ‘positive relationships’.
When you have finished you should have fully coded data and a completely documented codebook. It’s important to keep this codebook and the transcripts safe because the aim is that if someone was to repeat this exercise they would find similar outcomes to you.
We invited a small group of designers, product managers, business analysts and user researchers to help us with this. We had to devote a whole week to this process as we had a lot of transcripts to get through.
By following steps one, two, and three you have taken a robust and replicable approach to ensure that your data has integrity.
Step 4: Map your data
So you’ve got your data. You have coded it. It’s time to find the patterns and begin uncovering your personas. This is the time to bring stakeholders along, start building trust in your process. Invest their time and then they will be more likely to buy into the personas you produce.
This is when you are trying to find out if any of your participants share similar opinions and ideas in one theme?
This is when the traditional technique of affinity sorting comes to hand. If you don’t know what affinity sorting is you can read about it here.
We had 2700 minutes of interviews so we had a real need for keeping things organised. We extracted the data from Dovetail and moved it to Miro. Each piece of coded data became a sticky note. Basically, we transformed 45 coded scripts into a thousand sticky notes. Each sticky note contained a coded piece of information i.e a quote and the relevant code attributed to that quote. It also contained the participant number. We used colours here to identify different participants. So all sticky notes, containing all coded quotes belonging to participant 36 were coloured purple for example.
We then created a three-part scale template that was replicated for each theme. The sub-theme denoted the scale points on that theme. So picking up on our theme from earlier Relationships before prison, our three-point scale would go positive, mixed, and negative.
Then it was about matching! Did the participant have data on that sub-code? If so, we would move their sticky note with the relevant quote to the template.
By doing this we were able to visualize which participants had similar experiences, beliefs, and attitudes within themes and across themes. For example, green and yellow always go together or red doesn’t have any views on a particular theme, just like purple.
This will organically move you onto the next (and last!) step.
Step 5: Form your personas
Colouring your participants allows you to track which clusters of participants share the same response across themes but if you have got a lot of data like this, it might be hard to do this with the naked eye. This is when you can make use of computing power!
We decided to build a really simple algorithm on Google Sheets to do this for us but you don’t have to. Our algorithm looked for where participants shared three or more responses on our data points across all the scales we mapped. For example, participants who have the same reasoning for why they did the crime, maybe it was about money, they then also had quite negative prior relationships outside prison before they came in and they then also may have trouble maintaining relationships while in prisons, etc across all themes. The algorithm would tell us that seven people, for example, share these responses. It in essences tells us the persona group size and what the common data points are.
A computer is really good at doing that, much better than a human is.
Your personas sizes may differ in the number of participants they have, this okay, it’s just something to be aware off but you should set a minimum threshold for what a persona size is based on the overall number of participants. The important thing is not to set out expecting to find five personas, the data will naturally cluster into the appropriate number of personas if you set an appropriate threshold.
What makes personas work?
So you’ve followed the steps for producing the insight that goes into your personas.
So what’s next? How can you ensure your personas will work and won’t end up in a drawer?
When it comes to designing artefacts, here is what matters. Take a look at this complete example of one of our personas.
Our aim was that no matter where you delve into these personas, you should be able to take away a consistent idea of what that persona is. This way every type of learner should feel that these personas are accessible and not be alienated by the type of template they may have seen before.
These are the five personas we ended up with:
We associated colour to the persona card which reflected elements of the personality that we wanted to communicate. This colour tone was then used consistently throughout. For example, shades of blue. We also designed an abstract graphic, to illustrate a dominant feature of the characteristic. Here our persona Zeus is in charge of the wing.
Memorable symbols for visual learners
Our tag lines and names were carefully selected. The use of a greek god was to create a powerful and memorable anchor. Nobody remembers Dave the Marketer but you can be sure that something like a greek god sticks in people’s minds. We chose greek gods because we could align their fables with the own narratives of our personas. It’s also a provocation to associate prisoners with gods, forcing people to abandon their preconceptions of prisoners.
You could use any kind of metaphor elements for example or seasons. We would recommend staying away from purely human characteristics. It should be unique and easily distinguishable so that people can quickly refer to it.
We also put a snappy one-liner that acts as another summary point for this type of learner. This is something we borrowed from mythology.
Narratives for those who learn through storytelling
For more qualitative learners we wrote a longer narrative to tell the story of the persona. Data can often lose that rich storytelling perspective that brings the depth and complexity of an individual to light. This is something we borrowed from soliloquies in plays.
Quantitative data for those who learn through numbers
Lastly, we created these quick data points. For the more quantitative data consumers out there, these are quick reference points to summarise that personas key characteristics. This is something that we borrowed from anatomy. All of these data points are also covered in the narrative just in a different manner.
Don’t forget to Socialise those personas
We firmly believe that a person should not be strictly bound to the card format alone. There is no rule book that says personas have to be cards and only cards. We had so much data that didn’t make it into our personas that we decided to make lots of other assets.
Try and find new ways to communicate and share the knowledge you have spent time collecting. You have probably invested a fair bit of time in this so make the work you have done work for you.
Quote cards
We took all of the great rich quotes that we had and made them into 31 quote cards, one for each day of the month. In our workplace, we read one of these quotes out at stand up every day in front of the team to remind the team of our users and what they think. You could even give this to senior stakeholders to sit on their desk or set up a slack bot.
Website
Finally like all teams in COVID19, we pivoted to a digital world. We designed a website to ensure everyone in the organisation can easily access the insights we gathered and use them. The website allows users to interact with stories, quotes, images and audios clips that can help them empathise with the looks, sounds and people in prison.
Principles for good persona artefacts
So here are our principles. You don’t have to follow them to the letter but you should test what you produce against them.
- Make them inclusive
- Make them playful
- Make them consistent
- Make them accessible
It’s up to you now
So there we have it. We have talked you through it.
Your personas suck but you still build them the same way. If you weren’t convinced about that before, we hope you are by now.
Don’t keep pretending they are working, when you know deep down they are not! Getting things right for your users is what inspires you to go to work every day. You are their advocate and you shouldn’t be happy with the current way of doing personas.
The good news is they don’t need to suck. Now you know how to, build them properly. Do the thing, but do it better.
Get our resources and templates
We are still figuring out the best way to share resources and support you on the road to building personas.
If you are interested in staying up to date, register your interest so we can send you stuff straight to your inbox.
