Personas Deconstructed: Taking Apart User Assumptions to Craft Better Insights

Yeah, so thank you everyone out there for joining this talk. This talk is called Persona's Deconstructed, Taking Apart User Assumptions to Craft Better Insights. And just a little bit about me. So I'm Wilma Lamb, Design Strategy Director at Substantial. My background focuses on the intersection of design, technology, and business innovation, aiming to build new products and services using human-centered design and equity-centered practices. I'm also the host of the Optimistic Design Podcast, which just finished its second season. And then a little bit about Substantial. So Substantial was founded in 2006. We're a consortium delivering design research and strategy, product design, and full-stack development with our distributed team of researchers, strategists, designers, and developers across North America.

So diving into our topic today is common, I think especially for designers, but also more largely, product teams. To be asked to do research on cover, what really are the user needs for the challenge at hand? And how do we define problem spaces and come up with solutions? So in experiences that my team has had, this can encompass being asked to create personas, which is a tool which is used to capture an understanding of archetypes of users. So for example, we've had clients ask us, can you help us to represent uninsured diabetes patients? Or can you help us to create a framework that represents students that are struggling in school? Or can you help us to create personas to help us understand a new employee experience as part of a larger product design project? So let's talk a little bit for people who are not familiar about what personas typically are, and more importantly, why our team now is really rethinking how we actually approach them.

So most typically, user personas are conceptual representations created based on an amalgamation of user attributes of what we would consider typical users of a product or a service. So that's shown here has an image, has associated demographics, and a user biography to give some background and flavour as to who this hypothetical user might be. It seeks to tie in this user's motivations, goals, and behaviours, which are going to be used to drive the needs that need to be addressed with the product or service that we're building. They're meant to provide reliable, realistic representations of key users to help shape service and product offerings. And in many cases, can be a very useful tool if you have a very specific understanding of what is the problem space at hand. We have a very clear definition of what kind of product or service we are building.

But on the other hand, our team has also encountered that we would do design research followed by creating a persona framework that would follow the more typical method, where you've taken what we've heard from maybe dozens of end users and created these archetypes. But then when we go and we actually share it back with some of the end users that we've interviewed to validate and hear their opinion of what we've created, we can hear back from users that the details don't exactly feel true to what they said, or it doesn't fully capture the set of needs or complexities or contexts which they operate in.

So what's happened when we try to use a framework, like a more typical persona? So what's happened is that user personas definitely also have limitations. So it really depends on what you're trying to do when you're doing design research to understand. Primarily, this kind of framework can become reductive and it can be a static representation that looks at users at a fixed point in time and context. And furthermore, by showing a biography and demographics together with the goals and needs, it can lead to an incorrect assumption that actually those things are related. This is especially problematic when you're considering marginalised or underrepresented groups, as it can lead to stereotyping people's behaviours and needs.

So if we look at the example here, the same one that I showed before, you could also look at this and incorrectly assume that people of this age group, salary, and job generally tend to exhibit these same behaviours, motivations, and goals. And that's going to drive the kind of product or service that you should be designing for them. What it doesn't fully account for is how their motivations, goals, behaviours, and needs may be context dependent. And that may depend on things that are not necessarily represented on this framework.

So today, as our team's been reflecting on the need to, one, have something that we can bring to product teams to talk about, well, what are the needs of users and how do we define what our product or service can do? But there are two additional layers that we need to think about. So how do we move forward building flexible, nuanced tools that capture these insights but that also respect multiple contexts and spectrums of experience? At the same time, how do we also ensure that these are still easy to use by focusing on the most relevant information?

So what we've come up with over the last year is a new approach to thinking about personas, what we're currently calling attribute set personas. And this centres on the idea of a persona representing a specific set of needs and experiences within a specific set of contexts. So this is not trying to capture who somebody is in all aspects of their life, but really looking specifically at a contextual lens. So we focused less on defining specific demographic segments or even psychographic segments, but rather on defining the parameters of a specific context in which we're creating a product or service and how that leads to a set of needs or experiences which we can actually design a product or service against.

So to help us as we started rethinking what personas could be, we reviewed a lot of our previous design research and projects across multiple industries working with a variety of clients. And we're also looking at examples from the broader design industry. And out of this audit, we really started to try to identify, well, what are the things that really drive user needs and experiences? And can there be a new framework that we could develop that might be different from what we would consider, like a more typical user persona kind of framework? And what emerged from these conversations and kind of reviewing projects were examples, the one that's shown on this slide, which is from a project that we did looking at education technology, where a student talks about a specific context that shapes her needs and experiences, where she had shared with us, what I feel I need to do good in school changes. Like, do I like this class? Is the instructor good? Am I working a lot? Does it matter for my goals right now? There's a lot of different things.

And this was consistent as we looked across industries in different contexts, like the specific needs that were raised by end users vary greatly based on the specific context in which they are going to be using a product or a service. And what we identified kind of across different projects and industries is that there are four kind of general areas of influence that shape the needs and experiences of users. And these seemed pretty consistent from what we were seeing. And that was personal context, institutional system, situational journey, and mindset. So the first of these, personal context, has to do with how users' personal background demographics or previous experiences shape how they're approaching the current context at hand.

So for example, if we think about that educational example, we can consider what year is a student in school? Do they have older siblings that might have gone through this school before? Are there additional learning needs that we need to consider that are important context for how they might be using, let's say, a piece of educational technology? The second aspect is institutional system. So going back to that educational example, in this case, we would be thinking about, is a student going to school in a public or private environment? Is it a big school or a small school? What is their access to digital technology? What are the kind of systemic influences that are going to shape how they're going to be using whatever sort of product we're developing? And then the third area that we would consider is the actual journey of the user over time, so how different points in time lead to different needs and experiences. So we might consider the difference of a student starting in their freshman year, their first year of high school, through their fourth year. But we can also consider the journey over the arc of the year from their first day of class to their last day of that term. And how are their needs and experiences distinct? And what might they be looking for in educational software that's going to change over the course of that journey? And then the fourth aspect is mindset. So what attitudes and beliefs are users bringing into the situation that we're solving for? And what is notable with mindsets is that it can also change based on the other three factors. So a student that's in their first year or their first day of class may have a different perspective than a student that's on their last day of class or in the third year of school, for example. Or if they've changed schools, their mindset might be different.

So how are we also accounting for that and understanding the needs and behaviors of end users? So as a starting framework, kind of building off of those four quadrants, what we try to do is then begin to shape what are the attributes that come into play in each of these four areas. We pay attention in our research to what are the personal contexts, the different kinds of systems, the different points in the journey, and different types of mindsets that we hear about as we're interviewing end users. And how are we using that to start to develop an early understanding of the different flexible attributes that could be in play for a group of users?

And so most typically, what we're trying to develop is a larger set of needs and experiences that in total the product needs to consider. It's not that they necessarily need to design for every single attribute, but at least that they've considered each of these attributes. And then we're making a decision as a product team on, OK, which of these attributes are going to be considered for this product or service, and which of them are maybe not as core to what we're solving to now. The most important thing here is really that there's a conscious decision about which attributes are going to be considered. So to give an example of how this actually might work with a specific project, in this case, let's look at how we might approach a project related to maternal health experience to improve patient outcomes.

So for example, if we've been asked to create personas with the goal of understanding what is driving poor maternal mortality and maternity care outcomes in the United States, which is a multifaceted issue with many potential factors, we could use the attributes of a persona's framework we aim to capture the ecosystem of context and associated needs and gaps in patient experience that we might want to consider as we start moving forward with a project like this. So as a starting point, our team would typically do secondary research to understand the maternal health space, trends, as well as social listening to gain initial insight. This would often be followed with a series of interviews, probably several dozen, with pregnant people across different points in their pregnancy with a focus on understanding that end to end patient experience. To give additional context, we might also round out that research by speaking with health care professionals, including midwives, nurses, doctors, administrators, and other specialists.

And out of this research, our goal is to really start to shape, OK, what is the personal context that may be at play in this environment? What are the institutional systems? So in this case, we're really talking about the health care system that's going to influence and use their needs, behaviours, and experiences. And then situationally, over time, what are the distinct needs or experiences across that kind of patient's journey that might shape what a specific product or service needs to provide? And then lastly, how do those other three elements then shape different mindsets that end users might have? So in our initial synthesis for that work, we would start drafting what we think are a relevant set of attributes and then seek to validate these with user research, where we would actually bring back people that we had initially interviewed to then look at, like, well, here's some of the insights that we generated. Does a set of attributes feel right? And we would do that in co-creation sessions with people we'd interviewed earlier in the process. We'd be bringing them back.

So in the example that we're showing here, we've captured what patients have shared about their personal context that might impact their pregnancy experience. So they talked about things related to their support outside of the health care system, previous parental experience, financial concerns, health care access concerns. So these might be all things that are like their personal individual context is going to shape needs and experiences that they have within the maternal health system that we're trying to solve for. At the institutional system level, we've categorised the experience based not on specifically the type of hospital, per se, but on a type of experience and the level of support that patients report to us that they're receiving.

And so that's a range from, are they receiving relationship-based care, where they're really close to their health care providers, and they feel like they're able to access all the information that they need to be able to make informed decisions, all the way to maybe a rating that is more reactive care, where they don't feel like there's necessarily anyone in the health care system that's really being proactive about supporting them. And so there's a range in between where we're trying to understand how do changes in the system then change how you need to support that individual patient so that they have the best outcome possible. And then for the situational journey, we're really looking at major milestones over the course of pregnancy in this particular case, from initially trying to conceive all the way through postpartum as the major milestones. And then we would also consider additional events, such as pregnancy loss or transfer of care during the pregnancy.

And then lastly, we also captured major mindsets that stood out to us during the course of this research of thinking about a range of what pregnant people report as the mindsets that they use as they approach their experience. So are they more experience-oriented? Are they more knowledge-oriented? Or are they really milestone-oriented? They're trying to get to that next milestone in the journey. And so we start with all of these as flexible attributes. And then how we capture the insight associated with each of these attributes is we start to draft actually an attribute card. And each of these cards would then describe, what is the attribute? Is there a relevant end user quote that came out in the research that we think is useful for the product team to be aware of? And how do we describe this experience or goal and specifically highlight needs that might need to be addressed with a product or service that we're designing for within these cards? And ultimately, what the product team will have is a set of all of these attribute cards that can then be put together to represent a whole set of different kinds of personas that could be the end users of the product.

So rather than boiling it down to a more typical archetype of four or five, the cards allow for a much greater flexibility. And then we would continue to iterate on these cards. So often what we do is we create the cards, and then we actually will go back and do validation research, bringing back end users, having them actually try using them. So we'll ask, oh, we interviewed you earlier. We heard about your experience along with a bunch of other people. We've now generated these cards. Can you actually select the cards that you think are most applicable to you right now and talk us through whether you feel like these accurately represent the needs or experiences that you have related to a product or service that we're currently designing for? And what this really allows us to do is to get a lot more specific about what we need to design for with a product or service.

So here's an example with someone. So we had asked this individual to select cards that represented her early pregnancy experience and not the experience she had right at this moment. And she had said, I chose limited personal support because it took time to figure out how my family and partner could help me. I selected increased maternal age because I'm over 35. And I was originally at a local birth centre but wasn't getting the information I wanted. So this gives us a chance to verify that actually the attributes that we've created in these cards that the product team will be designing against are accurate. And they're seen as representing true user experiences. And we would do this exercise with a number of different users. We'd interviewed earlier at this point in the project just to verify. And we would ask them to do this not only reflecting on earlier experiences but also their current experience so that the team gets to understand how are these attributes also changing over time. And we're using it ultimately to identify opportunities and gaps as we're developing product and services to make sure that we haven't actually inadvertently left behind key contacts or key needs that would have otherwise been overlooked.

And so here's an example of we had asked this person to select cards representing their earlier pregnancy experience. We also asked them to do the same for their current pregnancy experience. And at this point, we're talking to them in their third trimester. So they're picking different cards. They're talking about different considerations that they have. And this process is really useful for our product teams just to understand the range of experience that a person may have. And I think overall, what makes this framework really useful for our teams is rather than making assumptions about a particular person or a set of personas and their needs or experiences, we're actually able to work with end users throughout this process and integrate the product team in how we're doing this kind of research to develop an integrated flexible approach to defining what's most important as we head into actually developing different kinds of solutions.

And it also helps us to uncover things that maybe we hadn't anticipated before and maybe to foresee more things that could be really important to consider as we're designing a product or service. And so while the example that I just shared is for maternal health, we've definitely thought about and used this application in other sorts of industries pretty effectively. And a lot of it just helps our team to really broaden our thinking about who are we really solving for, what are the wide variety of contexts and needs that need to be considered in a particular product or service development.

And overall, there's three takeaways for this talk. I would ask you to rethink the situation when you're asked to create personas or even if you're asked to create a set of insights that are supposed to represent all of your end users.

So one, try looking at personas as a flexible spectrum of attributes rather than fixed representations that are always true.
Number two, define the spectrum of attributes based on deeply understanding how they actually shape user needs and experiences.
And how you do that is item three, which is you partner with end users to really define, develop, and refine attribute sets.

So this is perhaps the most important to ensure that these are accurate reflections of user needs and experiences and to ensure that also your product team has a clear understanding of what they're solving against and that that fully captures intersectional contextual needs and experiences for the variety of end users that you may need to consider.

So thank you so much for listening to this talk. If you'd like to connect with me or learn more about this work and approach, feel free to connect with me on LinkedIn, email our team, or visit substantial.com, where you can also find the Optimistic Design Podcast. Thank you.

Rory
Excellent. Thank you very much, Wilma. That was really, really interesting. It sings to my, I don't know, I'm not a big fan of personas for all of the reasons that you mentioned there about the kind of static context and generalisations and stereotypes. So I really did enjoy that. But I have a few questions, and there is time for some questions. So one thing that just jumped out at me as you were going through, and I'm sure you might have gotten this question before, have you much experience with jobs to be done? And where is the overlap or difference do you see between your kind of context maps, or sorry, the cards and the context, versus, let's say, coming up with a job to be done?

Wilma
Yeah, I mean, I think some of it also depends on the stage of work that a product team is at. So most commonly when we've used these attribute sets of persona, attribute sets, we're doing it at a much earlier stage of product or service development, where maybe the business case itself is not as clear. So you're talking about needs and experiences as a high level. I think jobs to be done, to me, come into play a lot more when the business case is a lot more clear of, OK, we know what kind of product or service, and we know where it's going to go, and how we're going to sell it in. That being said, we've kind of been developing this framework over the last year. And so while right now the sets of cards we've created, they focus on needs and experiences, I think I could also definitely see a case for a product team further along, like updating their cards to change it to be more about jobs to be done, once it becomes a lot more clear what they're actually creating.

Rory
Yeah, great. No, I love that. Bob Moesta uses jobs to be done a lot more on the sales side. So I get what you're saying about it's kind of more for further down the line. One thing that jumped out to me is, so the problem with personas is that they're stereotyping or generalisations that aren't necessarily true. But then when I looked at your example, and it was great, and I really thought that it was very immediately useful, I could look at this slide that you shared and learn a lot from it. But one thing that I thought was, OK, that early stage pregnancy, and one of the attributes was older mother, or I can't remember how you phrased it. But that's going to be very specific to that person, whereas other people in early stage pregnancy wouldn't have that. So how many of these contexts do you end up creating, and how do you avoid it becoming a context of one?

Wilma
Yeah, I mean, I think that's a lot where we're looking at, OK, let's say we did 30 interviews. How often did this issue come up? What you're trying to bubble up to the surface is the most significant contextual factors. So in the case of pregnancy, at least in the US, actually your experience of the whole health care system when you're over 35, because that's considered a geriatric pregnancy, is actually different. The series of interventions that someone would experience and how doctors treat them is different. And so if you're noticing that in the interviews of, oh, this set of people is talking about this kind of experience, then this set of people is talking about a different set of experience, then that's a context you want to capture. We would certainly see other projects where, for example, age is never mentioned as a contextual factor. And so then it never bubbles up to the surface as something that we would capture.

Rory
Brilliant. And then, yeah, I guess just what did you end up with? So let's say you had 30. What do you try to reduce it down to, or is there a golden number or anything, or do you just kind of see what bubbles up?

Wilma
Yeah, so this is the part where it really depends, like our team will assess based on what the product team needs, what we need to create. So we've done some projects where it was like ultimately, so we have this set of cards. And we might have maybe for a specific team working on a specific product, we then might have them develop, like, OK, here's four or five personas that we want to focus on based on these sets of cards. And the biggest thing here is team choice. It's that they can look at all the cards, and they're making a conscious decision to be like, these cards are not a part of what we're focusing on, and these cards are. And what we're trying to check for there is that they haven't inadvertently left things out. If you're leaving things out, it's a conscious choice the team has made to be like, we can't solve for this issue, or these are just not core to our user base right now.

The other thing that we've seen teams do now is actually rather than creating a single persona, they look at the set of cards as a whole. And they're making a decision of like, OK, we're going to service these specific types of users and these specific needs because our product can cover this. And then some of these other attributes are not going to be part of it because our product cannot solve for these issues. And I think that helps us with some of the loneliness traditionally of like, oh, this persona is an archetype of all these people. Now it's more just like, well, our user group as a whole has these attributes, and that's what we're solving for rather than a hypothetical individual person.

Rory
Great. I could keep asking you loads more questions. I found that talk really, really interesting. I loved your approach, and I loved the visuals of how you kind of communicated it as well. So I think it's very powerful. So thank you very much, Wilma.

Wilma
Yeah, thank you so much, and thanks for having me.