This series was initiated as a place for you to learn more about service design and journey mapping software. Our co-founder Marc Stickdorn and the Smaply team share their experience on how to embed and scale service design in organizations. The sessions usually kick off with a short introduction to the focus topic to bring everybody to the same page, followed by your questions and deep discussions of best practice examples.
On this page you find the recording as well as the transcript. Additionally, the session is also available on Spotify, iTunes and Google Podcasts.
Overview
- [02:50] What are personas?
- [04:40] What is the difference between service design tools and methods?
- [08:30] What’s the connection of personas and market segmentation?
- [10:00] How do organizations use personas?
- [13:45] What’s the difference between personas and similar constructs?
- [17:30] Who uses personas and when?
- [20:40] How long do personas last?
- [22:45] Empathy map versus persona?
- [24:10] Personas on journey maps
- [26:00] How to evangelize and share personas within a remote company?
- [29:25] How can we avoid superficial personas?
- [31:30] How do you design behavioral personas?
- [34:50] How to incorporate personas into a design or development process?
What are personas?
A persona is a boundary object. It helps you to translate between different disciplines to make sure that people are talking about the same thing. Folks with a certain expertise can use this boundary object to distribute knowledge across different disciplines. In an organizational department, one team can use a boundary object like a persona to distribute knowledge across different teams, across the silos of an organization.
Often personas are used to visualize data. When doing research, we go out, we collect data. Primary data, secondary data, any kind of data that an organization has. We use qualitative methods, we use quantitative methods, hopefully we use a mix of those.
Then we interpret the data. Often in this process we actually use visualizations like journey maps, stakeholder maps, system maps or personas to visualize data, to make sense of it. When we talk about the difference of tools and methods in service design, there’s often a bit of confusion.
What is the difference between service design tools and methods?
A persona is what we call a tool. You can compare that to building a house. You need tools and methods. A hammer and nails are tools. Something you swing, you use for different purposes. A method is something you’re more flexible with. You can use a hammer – a tool – in different ways and actually make use of it differently.
In service design personas, journey maps, stakeholder maps are actually tools we use, while methods are rather activities: How we create our tools – for example through a co–creative workshop – or doing research, and how we then use our tools in different settings.
Often when we start creating our tools, we start assumption-based. We just use the knowledge that we have in our room to create a first draft of the tool, we love to use the word shitty first draft to free you from perfection, to really have something quick out there. But then you actually need to fill it up with data and you need to develop assumption-based tools like a persona into a research-based tool. Because only these tools are actually credible, something you can really use, you can rely on.
Whenever you see a current state persona or journey map that is based on assumptions – challenge it, and try to fill it up with with research data.
Personas represent a group of people, often we use them to represent a certain group of users that share certain behavior patterns or a group of customers. Could be also a group of employees or other stakeholders. In service design we often use the saying “Design for the average, test with extremes”.
Let’s take smartphone usage. From “I don’t have a smartphone, I don’t use it at all” to “I’m online 24 hours a day”. If you mapped out your users on a scale, you’d probably see something like a bell curve where you have the average user in the middle. Often for a certain segment – when we focus on a certain criterion – we design towards this average user. Whatever the criteria are that we use. But if you only focus on the average, you actually have the risk that you leave out a lot of other use cases, a lot of other behavior patterns which might not be the exact average.
That’s why we use the saying “Design for the average, test with extremes”. You also need to look at the edge cases, the extremes, and test for that.
If you make something that works for both ends – in the example of smartphone usage it could be those who don’t use a smartphone at all and those who are 24 online – then you can be pretty sure that you cover the entire segment.
What is the connection of personas and market segmentation?
If we think of market segmentation as you use some kind of criteria to segment the market. Hopefully you don’t use demographics, because demographics are often misleading. Still, organizations love to use demographics simply for the reasons because we have data on them.
Whatever criteria you use, all these little blue dots in the illustration represent a user. You map out these users on a map, you try to find clusters of them. This is classic market segmentation. You use criteria that help you to find these clusters, these bubbles. In these clusters you look for differences between the clusters; it’s called intersegment heterogeneity. Within the clusters, you look for similarities, so intrasegment homogeneity. This is market segmentation, classic marketing theory.
If you now start with using personas it might be also a good option to challenge existing criteria, look beyond the demographics and really try to understand behavior patterns that might segment your market much better.
How do organizations use personas?
I talked about the average user. Often you use a set of core personas in an organization. These are often the personas that you use organization-wide to represent certain segments of your market, if they’re based on certain behavior patterns. Core personas can be used to create empathy, to slip in their shoes, to design towards them.
You probably also need some of the edge cases – remember the bell curve. Probably you need more than two because you have more than two criteria per segment. You need a set of edge cases over time and develop them from project to project. That helps you to design for the average, but test with extremes.
The last bit on personas is a strategic element of personas. As you can see in the graphic above, there’s one segment on the lower left that does not have a core persona. On purpose! Strategically we don’t want that this segment is represented by a persona. One of the reasons why organizations do that is, if you don’t want to focus on this persona e.g., if this is a market segment that a sub-brand of yours is focusing on. Or it is actually a market segment, but you don’t want to focus any of your projects on them, you don’t want to design in this direction.
I work with a telco that has one of those segments and they call the segments the switchers. These are the folks who switch their mobile phone contract every 24 months, so whenever their minimum duration is off, they switch. They’re a premium telco brand so they don’t want to focus on those folks who constantly switch their contracts. They want to look into loyalties and keeping customers. That’s why they didn’t give this segment a persona.
On the other hand you can also use personas strategically to give certain people a face, maybe if there is not even a market segment. It could be that you want to develop a market, or a segment. Something we see more and more, that you actually give marginalized groups a face, maybe for corporate social responsibility reasons. That actually, by giving folks a face and using this persona throughout the organization, you might encourage projects for this group of people to arise.
What is the difference between personas, behavioral personas, user types, segments and archetypes? How do you create them?
There are so many similarities between that, so if I talk about the differences I’m probably talking rather about nuances on that. I think I covered the difference between market segments and persona above. Segments are often described rather in an abstract way, whereas personas really give you a face with the intention to create empathy.
If we look at different kinds of personas, we have something like: buyer personas that are often used in sales, behavioral personas, user types, and archetypes, that often represent what I explained as the core personas. They are like the average users that you have and they’re often just a handful – something between three to seven, that’s the same with the core personas. You shouldn’t have dozens of them because then people won’t remember them. Archetype users are probably like the most average users you see, but you still have multiple ones. It’s not only one archetype user. But those are the ones you can share across the organization.
Different kinds of personas serve different purposes. If you think of buyer personas, they are rather focusing on sales, sometimes on marketing. Focusing on the folks who actually buy something. And there’s a difference between the customer or the buyer – the one who actually pays for something – and the user, who’s actually using your product or service. Buyer persona are those folks that actually put money on the table.
In a b2b context, that becomes rather complex because there’s not one person in that, but you have multiple ones. You have a decision-maker, you have your internal champions, the ones who would like to bring whatever you sell into the organization but then you have procurement, legal, and risk assessment and all these other players involved. I work with some B2B companies who actually have loads and loads of customers, where it makes sense to differentiate and do personas for these different kinds of people. In a B2B context personas make only sense if you have loads of customers. If you only have five customers – you know your customers! No need to do a persona.
Who uses personas and when?
The data for personas comes from research and can be a mix of qualitative and quantitative research methods. If data doesn’t come from research initially, you want to eventually get there.
How you create them looking at those patterns and really sort of looking at what it is you want to understand and how your data falls into those patterns.
I use personas in a few different ways. I do a lot of work for government and in some cases when you’re working on a specific government service, there’s this sense of “everyone’s a user, so why do we need a persona?”; It has to work for everyone, we’re not doing a target market and saying these are the ones that are important. Everyone has to be important, but personas can still be really useful.
I use personas as a method and a tool in workshops. In an early project people weren't used to thinking empathetically, maybe there was a little compassion fatigue or they’ve been in their jobs for too long. In these cases it’s great to bring this idea of personas into a room and have people start to create assumption-based personas. It can give you a good starting point of: who do I want to talk to out there? How to find research participants? And it can also start getting people thinking about their customers this way.
The other way that I used them is as a really powerful storytelling tool. Again when you’re working in an organization where things haven’t been very customer-centric or user-centric, these personas can really help bring that face to people. Maybe there’s been some stereotyping, some generic "everyone-is-the-same" thinking in the organization and you really want to break that mold by bringing some powerful stories of real groups of people in. To make people think differently again. That’s probably how I’ve use them the most but that is not exhaustive.
If you use them in in large organizations, you can use them also to create empathy across silos and by that actually connect silos. I work with one large organization where they implemented personas quite well and it’s really interesting to observe how the employees talk about the customers. They use different names and and you observe there is that people saying things like: I’m sure if this works for Tom, but I’m not sure if it works for Clara. So they use it as if they were friends and everyone knows exactly what they’re talking about.
That doesn’t happen by accident, obviously that happens by design. It’s actually organizational development to bring it to this point. One clever thing they did, besides publishing, promoting, and giving trainings in it, is that they created large cardboard stand-ups of personas and put them into the room. If they had a workshop – and no matter in which department they use it – they put the relevant personas into the room. So they were visually there, they thought about it.
How long do personas last?
That really depends on how saturated your industry is and how saturated your market is. A very saturated market moves slowly and also behavior patterns move slowly. I would say it’s probably something like three years – but that is the maximum I see. Behavior patterns change depending on the impact of new technologies.
If you work in startups, if you pivot, if the market is not clearly defined, not saturated and not changing a lot, then your customers are changing a lot and you probably need to go down to something like six months, maybe even lower. Then you will not have as sophisticated personas but you rather use them and quickly iterate on them.
Going back to what you said about the names and people talking about them like friends. Hearing stories like that is what really changed my mind on the debate of ”do you name your personas using catchy behavioral titles like 'the conscious explorer' or do we want to name them 'Susan'. I am now convinced: we name them Susan and maybe we give them a tagline that helps us connect Susan to the behavior. But we want to humanize them as much as possible and that’s what’s going to give you the edge on embedding them into the organization and having people talk about them like friends.
To add to that – don’t use photos of celebrities! Even though we all would love that, but our customers most probably don’t look like Brad Pitt. Use realistic pictures, use realistic names. The tagline works really nicely. I think what’s also really important is to give personas a quote. What do they say quite often? That easily sticks in your mind.
Empathy map versus persona?
If you’re not familiar with empathy maps: it’s been developed by Dave Gray published in the book Gamestorming.
An empathy map (find a template here) basically gives you a framework which is really nice to develop personas, to structure your data. It goes around what do people see, hear, feel, do, say? What are their goals? It really gives you a nice framing for that. It’s often very useful on your way to develop personas as a kind of middle step. If you do your research, take an empathy map to structure your research data. Also to see blank fields, like “Where do we lack some data?”, “Where do we need to go out and do some more research?”. You can use that to actually transform into personas afterwards.
After creating these personas my plan is to create journey maps, representing each persona. Does that seem reasonable?
Yes, absolutely! That’s beautiful on journey maps, that you can actually add different personas to it. It often depends on the scale of your journey map.
For example, if you visualize an end-to-end experience, like the very high level perspective. Often on this perspective you don’t use personas because you just want to have a big overview, the main structure. But the more you zoom in, the more differences between your different user patterns you see. That’s where personas come into play. That’s one reason why in our software Smaply you can actually add multiple personas and create different journeys from them.
You can also create one journey and then duplicate this journey within one map, so you have one emotional journey which shows different graphs – each persona’s emotional journey in different colors – and you can compare. For example different user personas, so different behavior patterns, or you compare customers with employee journeys and put them into perspective.
Personas are a very flexible tool because you can not only use them for your users, you can use them for your employees and learn about different behavior patterns or behavior traits. That sometimes gets really interesting.
How to evangelize and share personas within a remote company?
Of course remote is always slightly more difficult. The example I gave with a cardboard thing is nice, but that doesn’t work for remote workshops. There are a few things you can do.
On the one hand, include them in your onboarding. When you onboard new colleagues, make sure that the personas are one part of that, so they learn from the beginning who your users are, what different types you have, how you call them and so on. Some organizations do that in a very structured way.
I would recommend to check out the handbook of the Deutsche Telekom design department, called “Design Thinking Doing“. In this book you see how they actually talk about different tools and methods, how they call it and in the printed version they even put their personas in. They use it to for training purposes, for onboarding purposes.
We can learn from that: if you already include personas in your onboarding, people are already familiar with them. That is actually how you bring a culture to life: you live it, you talk about that, you make sure that any kind of digital platform you use that maybe you also represent personas in it.
If you use any kind of live white-board software, you can create little avatars for them and put it in there. Just as a visual clue.
Remember: whatever you’re talking about, this is probably one of the core reasons for your meeting. If you then standardized tools at some point and you use journey maps, journey mapping software: make sure that for every project that you create, you have your personas in there.
If you use Smaply for example: create one project with your standard personas in it and – instead of creating a blank new projects – always duplicate that as a template. So you always have your standard set of personas already included.
How can we avoid superficial personas?
I just have a very quick tip: Don’t start with demographics. Do not start with age, or gender, or the income, or whatever. Rather start with behavior patterns, behavior traits. If you start with stuff like age, gender and so on, then you often already stereotype. But if you start with behavior patterns, then there’s a bigger chance to avoid stereotyping.
Nicole:
I feel like I am still learning about that. I find it really interesting creating personas and sometimes you realize: You’ve made them all look kind of the same. And then one of your more culturally diverse colleagues says: “Hey, can we change some of these names and some of these looks and get a more diverse group?” … and you go “Oh wow, I didn’t even realize I did that!”. So that’s one thing: keeping diversity in your personas, but then you also still have to make sure that you’re not stereotyping.
I think it’s most important really to understand what the stereotypes are that happen in your organization and then fight against that. If you’re in a department and with services that help vulnerable populations or populations that are deep in poverty, there are some specific stereotypes that can come with that. So those are the ones you want to fight against. I think it’s identifying the ones that you don’t want to replicate, so that you can be purposeful. That’s one of the best things that you can do.
How do you design behavioral personas?
This is such a big topic that I would refer to a really awesome colleague of ours, Kim Goodwin. She published the book “Designing for the digital age” which is absolutely fantastic. In this book you find a few pages about personas and some tips on how to develop them.
Something I really like is using what we call 'semantic differential'. You saw that criteria that I use for the bell curve “How often do people use their smartphone?”, ranging from 'none' to 'always'. If you do loads of these pairs that are mutually exclusive, you can then map out people and create profiles between them. This way you can see: where do these overlap? Where they overlap you probably find a good starting point for personas. If you see that some criteria actually are not useful to differentiate, then you can leave them out.
One very hands-on tip: if you don’t have enough time to go out and do proper research and develop personas in the real research setting: get frontline staff in a room together! People who are in direct contact with your customers – be it on the shop floor, be it in sales, whoever is direct touch with a diversity of customers. Let them create personas!
Let’s get maybe 20 people in a room, split them up in subgroups of two or three people and let them create five to ten personas per group.
It will just take an hour or two and you will end up with something like 200 personas. Then you let them present their personas in the meantime you observe the room. You will see that some of the other folks will start nodding, or laughing, or pointing towards that, saying “I know exactly what you’re talking about!”. By that you actually already triangulate your research.
You already see: Does this persona resonate with more people? Then it’s probably existing out there, at least elements of it. Or is it actually an edge case that maybe doesn’t resonate with so many people? Then you can use the group to cluster them – and probably, within one day or less, you come up with quite robust personas. They are not really based on research, but based on the experience of people who have a really good knowledge about your customers.
What is the most effective way of incorporating personas into a design or development process?
One element I already mentioned in the beginning, that is the the saying “Design for the average, test with extremes”. Think about your core personas, but also think about a wider set of personas covering the edge cases. If you only focus on the one persona, there’s always a risk that you leave something out.
Think about diversity when you create your personas. Diversity in all their fragrances that we have, because often the people who design personas are rather homogeneous. For example a research team: maybe the similar age, similar education, even same gender, same skin color and so on.
But your customers are not like this. Diversity is one of the keys to the great power that personas can bring to your organization. To actually think about diversity, have a representative of different customers in the room.
If you design for everyone, you are designing for no one.
So you need to start with someone. Make a decision. Start with one persona and design towards this persona. Take the average user for that, the average of one particular segment, one of your core personas. Once you have a prototype for that, don’t go through the entire design process, until you launch and only test it then. As soon as you have a prototype, start testing it with the edge cases and you will learn a lot about that. You will iterate your prototype.
Depending on the feedback of that, prototyping can be done by imaginative prototyping. Put this persona into the room, hang it up and think about “How is it for this persona?”. It’s much more powerful if you actually invite representatives of this persona, some real people. Prototype with them and see how they react. The personas are a great guideline for you to select the folks you invite for prototyping. Make sure to invite a diverse group, at least for the core differentiator between your personas.
And now, what's next?
Learn more about the basics of personas, or check out more Ask Marc sessions about different topics of human-centric work, like multi-persona maps, creating CX insight repositories, and many more.
