Personas - a definitive guide for UX designers
Personas have always had a significant but conflicted place in the UX (user experience) design process. When they work, the values and benefits of creating personas are undeniable, and yet, there are numerous product teams that can attest to having created personas that lie around collecting dust in their respective companies. In this article, we'll do a deep dive into personas as a research method — What makes them such an effective tool for user-centered design? And how can we make sure that creating personas does not turn into an exercise in futility?
What is a UX persona?
Before we get into the why and how of things, let's start by defining what a UX persona is. This is important because personas are not a concept unique to the field of user experience. It is not only a relatively common english word, it also has namesake concepts in fields such as marketing. The definition of personas as a UX research method is unique to the field — A UX persona is a fictional surrogate user that highlights specific behavioral and demographical characteristics of a group of real target users.
Personas in UX, help keep specific archetypes of users in mind during the design process. In other words, users who exhibit similar goals, mental models, and attitudes relative to our product, can be represented by a UX persona. This is different from a marketing persona which is less specific and focuses mostly on demographics. They tend to focus on what messaging will result in more sales whereas UX personas help inform product development/design decisions.
Personas are also not averages of demographic variables. For example, a single person vs a 100 person team may average out to a 50 person team. But the needs of a 50 person team will be very different compared to a single person.
Being clear about this distinction is the first step in increasing the efficacy of using personas in research. Now that we have a good grasp of the definition, let's talk about why we need personas at all.
Why do we need personas?
Ok, so now we know that personas are surrogate users that represent a group/cohort of real users. But why do we need them at all? Why can't we just talk about real users and use them as the measuring stick for our product requirements? We will answer this question by discussing the several advantages of using personas to inform our UX design.
1. Avoid the elastic user
Let's answer the question we just framed first. If I were to ask you to think about your product's user. Which user would you think of? The last client you talked to? The last person that complained about a feature? or perhaps the customer that's paying you the most money?
Now imagine, in a meeting with your stakeholders you say something like — "Our users would really appreciate feature X". Every person in that meeting would have their own mental model of the "user" when you make that statement. Some would agree with you, others won't, simply because they're thinking of a different user. This phenomena is referred to as the elastic user.
An elastic user is a generic user which means different things to different people. Designing for an “elastic user” happens when product decisions are made by different stakeholders who may define the ‘user’ according to their convenience.
— Nick Babich (Adobe)
Now imagine making the same statement but referring to a persona — "Sally, the marketer would really appreciate feature X". Instantly everyone in the meeting has the same mental model of the user persona you're talking about (provided the stakeholders are familiar with the personas). Now the discussion about the validity of your statement can be a lot more fruitful and focused.
2. Leverage a memorable shorthand
In general, human beings are not very capable of remembering a list of items, attributes, behaviors, etc. But one thing we've evolved to be good at, is remembering other people and their characteristics. Personas encapsulate a personality and its traits behind a face and a name. A concrete representation of a human being is much easier to get lodged in people's brains than a set of demographical or behavioral data.
So, arguably the most important benefit of a persona is that it gives everyone on the team a common and more precise shorthand for a cohort of your target users.
3. Avoid designing for yourself
The main difference between artists and designers is that design is for others. Even the most seasoned designers though, sometimes fall prey to the self-referential design decisions. Some things seem so obvious to us that we fail to see it from anyone else's perspective.
Personas help us stay true to the user-centered part of the design process. We are almost never designing a product for ourselves. Having the personas constantly in our mind as we make design decisions help us stay away from making biased assumptions.
4. Avoid designing for every use-case
On the opposite end of the spectrum, is what tends to happen when there are no personas. We have all experienced this either at our jobs or as users ourselves of other products — Featuritis.
Featuritis - A disease that affects products if individual users and their feedback are left in-charge of prioritizing features in our products.
This is specially apparent in enterprise applications - tons of features, buttons, hidden menu items. Every one of them could potentially be traced back to - "An important user asked for it".
Personas by default represent a cohort of users so if we are designing with a persona in mind, we're never in danger of over individualizing the product experience.
5. Easy knowledge transfer
Very often in our careers as UX professionals, we need to collaborate with an outside agency or get a new hire up to speed. Personas are instrumental in conveying a complex amount of information and answering the "who are we designing for?" question, relatively easily.
How do you create an effective persona?
So now let's get into the meat of it. If you've been in the industry for a few years, you've more than likely come across articles and resources that talk about the benefits of personas. But very few of them actually delve into how we create personas that work? In this section we'll talk about what should and shouldn't be part of personas and more importantly, how do you come up with the content.
Anatomy of a UX persona
At the very basic level a persona is made of mainly 3 kinds of content - memorable, demographic and behavioral. Several amongst us fail to understand that all these pieces are essential for a persona to work.
- Memorable content are characteristics of personas that are added to make them easy to recall. Example – image, name and tagline.
- Demographic content are things in users environment, things that describe them. When you're tagging your research data, the segment tags we use almost always fall into this category. Common examples - team size, health problems, age, role, where they live, etc.
- Behavioral content are related to things that users do, want to do, are frustrated about doing, etc. During coding, these are things that we generally add highlight tags to. Examples - "tracks water along with food", "embarrassed to share food pictures", "Doesn't care about macros", "Unhappy about the confusing screen", etc.
Great, so how do we come up with the content?
The first thing to remember when thinking about creating personas, is that all personas are based on real data. This means we need to do research on real users before we can begin thinking about personas. We need raw data to pluck demographical and behavioral data from. So where do we get raw data? Interviews! Yes, there are other passive methods like surveys, feedback repository etc. But, by far the best method of getting qualitative data for research is conducting user interviews.
A rough framework to follow when a new project/feature comes down the pipeline is the following:
Step 1: Stakeholder interviews to get clarity on feature, constraints, timeline, etc.
Step 2: User Interviews to collect data on users and their behavior around the feature.
Step 3: Synthesis.
For the scope of this article, we will talk about Step 3 in more detail. What exactly are we doing during synthesis? The goal during synthesis for personas is to identify what is different amongst our users - both in terms of demography and behavior. And then, bubble up overlaps of segment tags and behavioral tags. Let's look at an example:
Here, the category is age range and team size. Each tag within the categories represents a scale range to bucket the users in.
Here the category is pain point and feature request. By tagging research data with these behavioral tags, we are automatically categorizing them into respective buckets.
Next step is to bubble up patterns of similarity and differences between users by identifying where majority of users with in a segment have the same behavioral trait (pain point, feature request, motivation, etc). We can certainly try to do this manually or in excel spreadsheet, but with large amount of data, doing this manually gets really cumbersome. UserBit makes this analysis a breeze by automatically keeping track of tag frequencies. All we have to do is click on the behavioral tag and look at the segment aggregation section:
Here, we can see clearly that older, suburban users are embarrassed to share picture of what they eat with strangers. (Sample size here is small since the demo project doesn't contain as much data as a realistic project would). We can discard evenly distributed segment aggregates within the same category. In this case, whether our users are technical or non-technical, they seem to both experience this pain-point so persona-wise, that segment category is not relevant.
Once we have gone through our behavioral tags and collected our findings we would have the skeleton for our personas with statements like:
- Older users, suburban - embarrassed to share food with strangers
- Older user - not concerned about macros
- vegetarian, young - wants to track water intake
Now we just have to cluster the statements pertaining to the same segment tags together (sometimes combining a few) and we can flesh out our personas with relevant content.
When should you make a persona?
"As early as you can" seems to be the ubiquitous response to this question. However, as we've just discussed, personas need to be based on real data from real users. This necessitates interviews and gathering of raw data to precede creating personas. However, personas should definitely be created before any real interaction/visual design work. It just makes those steps so much easier for the reasons mentioned earlier in this article.
Does this mean that if you're in the middle of a project or product development, there's no use of creating personas? No, There are quite a few benefits of having personas even after design work has begun. A common one is for handing over knowledge to new hires or contractors. It makes communicating who we're designing for, so much easier than having to describe it via the elastic user.
Why do they fail?
Let's circle back and address a statement made at the very start of this article. There are countless personas collecting dust in several companies. Why? The reason has less to do with the effectiveness of personas and more to do with whether we truly understand how to create/use personas. Here are a few pitfalls we need to avoid when using personas in UX teams.
Creating personas in a silo
One of the most common reasons for personas failing is that one person is left in charge of it who does the hard work of research, synthesis, creation, and socialization. For a persona to be useful, every member of the UX team (at the very least) needs to be involved during its creation. Why? Because the team needs to see that the persona is coming from real data from real users. Believing in a persona is essential to their efficacy and a team that thinks it is imaginary just won't have the necessary conviction.
Creating personas without research/interviews
There's a reason this point has been hammered multiple times in this article. Time and again We've seen teams begin their process by creating personas based on their mental model or their stakeholders' mental models. This just doesn't work. Personas need to be based on real users and their environment. Designing for imaginary users will result in products only imaginary users would want.
Adding too much clutter
The point of persona is not to make it an encyclopedia of information. Remember that for personas to work, they need to be memorable. Only information relevant to business use-case should make it into the one-page persona. If the content is not able to fit within a standard A4 paper, it's time to evaluate whether all that data is needed. Personas are living documents and they evolve but care should be taken to keep it short and relevant.
In the same line of thinking, a persona is also not an art project. Adding too many images and beautifying a persona is not going to make it more effective.
Lack of understanding of personas as a UX research method
Let's face it, UX is a vast evolving field and there are so many topics we need to be well-versed in that we are bound to skim over some. A lot of us (I was one) think we have a good understanding of personas and how to create them because we're familiar with word 'Persona' in the english language. Personas are also used in other fields where their purpose and positioning is different than in UX, adding to the confusion. A lot of us have learned the hard way that in UX research when it comes to synthesizing good data, 'winging it' never really works. Personas require proper study, practice, and understanding to be effective.
Congratulations on making it to the end - we've gone through what a persona is, how to create effective personas, and also, some of the common reasons they fail. I hope there's enough here to get you started on personas the right way. It takes study and practice but once it is integrated into the design process, personas not only have the potential to streamline the process, but also make it a whole lot more user-centric.
You can collect research data, synthesize it and create your personas, all on UserBit research platform.