Practical CX - How to Develop Personas for Design & Marketing

Alot has been written about personas since they were invented by Alan Cooper of CPE, but most of it (in our experience) misses the point. So based on research and experience, here's our guide as to what personas are, what they aren't, and how to create and use them effectively.

Defining Personas

To understand personas, we must first have a good definition of what they are, and why we use them. As such, we need to frame some context before we can get to the definition.

Firstly, personas exist as a design tool, and all good design starts with ethnography; going out and seeing how people do something, talking to them about it, and learning through problem exploration, and user observation & conversation. Its through this process of meeting, watching and interacting with people trying to solve a problem in the real world that we get to learn what they're trying to do, and see how they're trying to do it. As a result, personas can never be something invented in a room without research. A persona should always model real-world, observed use-cases.

Secondly, personas exist to show what matters. Not all data gathered in user testing and user research is going to be equally useful. Not all users behave the same, not all of their intended outcomes will be equally valuable, and the challenges they encounter will not be equally costly to address. As such, we need to group the results of our research through cost/benefit analysis, looking at both financial and time-based implications, and the scale of the benefit which would be created in terms of number of users impacted and improved revenue, ROAS and cLTV.

Once that research has been conducted and the results analysed, we can build a persona. Which gives us our definition for what personas are:

PersonaAn archetype built from ethnographic research, representing common behaviours observed in a goal-based scenario.

Building Good Personas

There's an art to this, as there is to most things in marketing. It's a skill, which starts with the understanding of what a persona is. As we've just defined, it's fundamentally a data visualisation based on ethnography. Which means to create a good persona, we need to start out with good research. So to back up a level, what makes for good user research?

In Person Research - The Foundation of Good Personas

Firstly, all user research starts with asking questions, so we need to know what kinds of questions to ask. When talking with users, binary and leading questions are a no-no, because they at best shut down conversation, and at worst lead the user towards approval-seeking and hypothetical behaviour. People are, in general, very poor at guessing how they will act in a future scenario. Instead, always ask about something where they can be objective, based on their experience and data.

Therefore, the best questions are things like:

Tell me about the day to day experience of your job, and what you do.
How do you accomplish the tasks you do each day?
What are you trying to achieve through these tasks? What's the end goal you're trying to reach?
How do each of the steps in those processes make you feel?
What tools and systems do you interact with in the process of working through these tasks?

You'll notice these are all very open-ended questions. When we conduct user research, the first rule is to ask something which lets the person talk, and then to shut up and listen. You're not trying to help them at this point, you're just trying to understand their life in this context. Pay attention to them. Listen attentively. Be present. Then after they've spoken, repeat back what you've understood to them, to make sure what you've picked out of what they've said matches with what they thought they were saying.

Once you've got your suite of interviews, you then need to group the common factors in the stages and steps of the journeys people described. Feel free to create these clusters however makes sense to you, and given the data in question. When we're doing it, we like to use the following:

The goal for each step and stage, as well as the final goal of the journey
How frequently and repetitively any action is undertaken
Emotional states before, during and after a step, as well as the emotions a user expects to encounter during it
The self-reported user skill level, and the actual observed skill level

Or, in short, how much users do a thing; how long they do it for; how they experience it; and how good they are at it. The reason we like these criteria is they're all things which are susceptible to cognitive bias, and which can be quantified by the user before you watch them go about their work, and whilst during it. That qualification by value is what allows us to cluster the responses to find commonality, and outliers, in the group being observed.

Data-Based Research?

The second method of getting information is through conducting digital and data-based ethnography. That means starting with end goals that users care about, and examining how they go about doing those things. It's a key piece of research to conduct before you go and do real-world research. Why? Because it turns unknown unknowns into known unknowns; it shows things that happen in the system you're going to try and refine which you didn't know about, and tells you to go and find out why they happen. It shines a light on what we don't know.

As a result of this though, it can only ever be a supporting piece. It can never be the whole piece of user research, because whilst it will tell you what people do, it won't tell you why people do it, and any guess you make to explain their behaviour will only ever be that: a guess.

So by all means, use your Analytics package data, but don't think it's able to replace actually talking with real people about what they do. Instead, think of it as a pointer, showing you where to look for your real-world observation.

Personal Experience Mostly Doesn't Count

This is also why you can only use your own experience of a field if you were in it before you became active in an organisation around it. As we discuss in the Strategic Thinking part of our guide to digital customer experience design, "By simply being in the business of selling to a market, you're already biased in ways which make you estimate incorrectly about that market".

If you've been a part of the audience you're researching for significant time, then your experience from that period is usable. However, if you're evaluating an industry for the first time, any related experience you think you have doesn't count. Also, your experience is only one data point, so even if it's valid, you still need to go and get more, because you don't know how much is just how you do things, versus how much of your behaviour is something which is broadly applicable. Experience design is always about deal with people in aggregate, and you are only a sample size of one. Go and get more data.

Only ever build personas from real, observable data about how people act in the process of achieving specific goals. You can't create personas from hypotheticals; you must have context for users' methods and ways of working.

Who to Talk To

If you've got your thinking head on, you might have noticed that we've only talked so far about users, not about customers. This is because they're often not one and the same thing. Customers are the people who buy a thing, which is often (but not always) the person who uses a thing. When they are, great, that makes the job easier, and from a business revenue perspective, you need to appeal to customers first, because they're where the money comes from. However, you also need to satisfy users. Notice the difference between the two - for customers, you're aiming to create desire and purchase impulse. With users, you're aiming to deliver a product which helps them meet goals in a pleasant way. This is why both customer journey maps, and user experience maps both exist. Because often you'll find they're two distinct groups of people.

Now, when we're talking about marketing, we should create unique personas for both groups. When we're looking at product design, distinctiveness and differentiation, we're fundamentally thinking about users. When we're looking at comms, advertising, pricing placement and distribution we're thinking more about customers. Remember, users are trying to achieve goals to complete work. They desire utility. Customers are trying to purchase products or services to meet needs. They desire value. It's a subtle, but important distinction.

As such, personas built from data for each of those two groups will often have differences, because the criteria required to meet the goals for each group are different.

What Not to Include

In Hirundin, there's a tool for building personas. In the interface, you'll find nothing about age, or culture, or anything else to do with demographics. Why? Because demographics have nothing to do with personas. Psychographics, relevant physical details and firmographics can be, but demographics? Not so much.

Let's kick off with a definition for what demographics are, before we go into why:

Demographics: The statistical characteristics of human populations (such as age or income) used especially to identify markets

Source: Merriam-Webster.

The why is that when we talk about demographics, what we should really be talking about are psychographics and physical characteristics. We use age and gender and cultural background and so on as proxy causes for behaviours. The problem is they lead you to stereotype, rather than thinking about the details. And marketing is all about the details. We're in the business of looking at how people think and work, and anything which is not directly about what people do, how they do it, and why they're doing it, has no place in a persona.

What we need to avoid is including data which leads us to think based on hypotheticals, generalisations, unconscious biases and "isms". The problem with demographic data is it directly leads us to this type of thinking, because it's easy. For a better explanation, let me introduce author, researcher and Nobel prise winner Daniel Kahneman:

To flesh this out a little more, let's say that you're conducting research into a physical product. Something like an audio device, where the degradation of hearing acuity over time plays a role. Or an app for people with Alzheimer's, where cognitive function is impaired. Then you might feel tempted to include notes on the person's age or health. However, these things aren't the relevant factor, they're what causes the issue encountered. What you need to note down is the level of impairment to the task, and what form the impairment takes. The latter gives you data on how you can address the issue, given what they're trying to do. The former leads to designing solutions based on unconscious bias.

You can't simply make a person with issues around mental acuity, hearing accuracy or fine motor control better. What you can do is design solutions in ways which are inclusive to users, based on the challenges you observe them facing.

Where and How to Use Personas

So we've gone out and done our research, we've collated our findings and found the common issues faced and the common areas which work fine when attempting to create certain outcomes. We've then compiled the findings into Hypothetical Jane who's tasks X, Y and Z, with the aim of achieving goal φ. What do we do now? Well, we'd generally use personas for four things:

Determining product functionality, behaviour and interfaces
Communication facilitation
Test and refine solution efficacy
Create pan-marketing user standards

Let's unpacking these one by one...

Determining Product Functionality, Behaviour and Interfaces

As we mentioned a little earlier in why demographics shouldn't factor in to personas, what we're aiming for in our research is to design solutions to challenges. With a properly built persona, what you have is a pile of context around what people do, and why and how they do it, when they try and achieve a goal.

This lets you frame solutions to the challenges they face in that process. If there's data they need which isn't exposed, you can find ways to show them that. If they find something frustrating, or there's a step which is highly repetitious or slow, you can design solutions to ameliorate those issues. And all challenges in the domains in which we work are fundamentally solved by one of three things:

Expanding, refining or removing functionality to hone the product or service
Altering the flow of a process and the way in which it operates to deliver a better emotional journey
Improving the design of interfaces to better serve the user and their needs at a specific point in time.

Each of these are things we can do, once we understand who we're doing them for and how to measure the success of our solutions, based on the users who'll encounter them.

Communication Facilitation

There are three groups of users in any project: the team working on a thing, the other teams involved in the project, and the stakeholders. All these need to work in concert towards serving the needs of a group of users. That means they all need to be able to communicate clearly and passionately, but also impersonally.

Personas are a great way of enabling this sort of communication, when it comes to discussing functions, behaviours and interfaces, because it stops discussion becoming about what someone things or feels, and instead forces any debate back to the evidence. Rather than " I think this should work this way, because I...", we end up with "I think this should work this way, because we saw Jane...".

That's a huge difference, which helps diffuse otherwise difficult situations, because whilst a personal opinion can be argued back and forth, what actually happened and was seen cannot.

Test and Refine Solution Efficacy

We hinted at this in the production functionality, behaviour and interfaces section above, we can use personas to improve the solutions we currently have. It's highly unlikely that every part of the journey users encounter is going to be perfectly optimised. Even when we roll out amends, we'll discover side effects as a result of our changes.

By understanding the issues encountered, when we present solutions to users, we can observe how the new solution works in practice, and also learn how effectively and efficiently different potential solutions meet the brief. Though this process we can triage different options to find an optimal solution, given the time and budget constraints which will inevitably be in play.

Create Pan-Marketing User Standards

Marketing is not just comms, as we often say. It's product, pricing, comms, distribution and experience. Having a robust set of personas lets members across all those functions have a touchstone to refer back to, which acts as a source of truth. It's something which can be reliably called upon to understand how people will likely respond to any change made to any of those five factors.

This unites everyone's thinking in working for the benefit of the customers and users. It pushes the organisation towards operating in a custom-centric manner.

It's this deep understanding across teams which means that John Lewis knows they can create advertising like this, and it'll work:

A Couple of Examples

Let's look at two examples to see why. First, imagine we're working for a company which sells bikes. We go out and we look at people buying bikes. We ask them what they like about their current bike and what the dislike. We observe where they ride, how they travel to and from there, what the use cases are for the bike. We see where they live and where they store the bike. We learn how fast they need to travel, what's on the route with them as they ride, how busy the areas are and how they feel whilst they ride. And then we go away and make a product that meets their needs.

That's how you end up creating Brompton bikes, and then reinvent your product again to create the Brompton Electric.

Real world study of people encountering real problems, and then designing solutions to meet them.

Now let's imagine we're an ecommerce store selling jewellery. We go an sit with people ordering jewellery. We conduct user testing of people using competitors sites, to see how users interact with their interfaces. We learn what matters and what doesn't. What people care about. Where they find value and utility. How they want to accomplish the tasks involved in research and purchase. Then we go out and create 77 Diamonds, because we realise there's a large customer market for buying the stone they want, at a good price, and having a custom fitting. The product, business model, distribution, pricing, experience and comms can all be designed around meeting a specific set of real user and customers desires and journeys.

In both cases, we look at how people operate in the real world, make notes about their behaviours, look for the common factors, and then design solutions to address the issues they encounter. Fundamentally, that's why we create personas - they let us live in the skin of the user and the customer. They let us imagine their situations, and then design to address their needs.

Ultimately, that's the real value of personas, and why we go about building them.