The Failure of UX Personas and How to Make Them Better

Okay lovely. Awesome. Okay. Um, so the failure of UX personas and how to make them better. Next slide. Hi, I'm Alex. Um, as you can tell, I'm a cat cat person. I've got two cats. That's one of them. Her name is uh LBC. It stands for little black cat because when we got her, she was little and now she's fat. So, it stands for large black cat. I am the UX research manager for US Bank and I'm a huge data nerd and clearly a very big cat lover. So within US Bank, I'm actually the research manager for two separate subsidiary teams. So the first is TAC point of sale, which is a point of sale offering for business owners when they need to basically have a register or uh split a check. Think of, you know, somebody being able to take a credit card and swipe it from their phone or, you know, be able to send a kitchen receipt to the printer in the back of house. We work a lot with restaurant, retail, um, and and, you know, a plumber comes to your house, does a project, charges you right on site, and and, um, you pay for it. That's all point of sale. And then the other research team that I run is Alibabon, which is the credit card processor. So I primarily work in the business and small merchant space as my my focus which is the business line but I kind of run research with subsidiary organizations of US bank and then partner with other US bank researchers. Next slide. Okay. So uh the failure of user personas and why I hate them. So firstly, we'll just kind of do a high level of what is a persona, which is an archetypical user whose goals and characteristics represent the needs of a larger group of users, which include a few fictional personal details to make the persona a realistic character. And it's the second part that I have a huge problem with, which is we include a few fictional personal details sort of sprinkled throughout these other valid data points in an effort to make this character more realistic. And so I'm sure many of you here listening to this presentation have seen something like this. Um, and and I have to give a caveat. What you're seeing on this page is a little bit of my uh crash sarcasm and uh snarky personality intertwined with real things that I have pulled from personas that I have utilized in prior companies. And so you see something like this. You've got your very generic stock photography of of somebody who is a, you know, uh, phone found online image photo, but not a real person. You've got a madeup name, and then you see something like self-made, rooted in family, but I don't actually exist. And then here's a fake story about me, but it seems real because I put it in a script font, and I'm outwardly assertive, ambitious, and constantly in action. And and I laugh at these things because the self-made and rooted in family is something that I actually pulled from a real persona that a business used to use. The um assertive and ambitious and constantly in action. Again, these are real pieces of information that I've pulled from actual personas. Then you've got these kind of very obscure details which really don't tell us a lot about this persona or how we're supposed to utilize them. You know, he's male, 36 years old. He's a cat photographer. He's married with six cats. He likes looking fashionable, you know, lots of hob hobbies, loves making his own beer and going to micro breweries. And the funny thing about this last part is this was actually given in a very large scale demonstration for a company that I worked for and they were talking about a business owner and they they included this detail and the the persona I think they used at the time his name was Mark and we were talking about small business owners in a business line segment and I said, "Oh, excuse me." I said, "Is Mark No, you're fine. I said, "Is um is Mark an alcoholic?" And they're like, "Excuse me?" I was like, "The comment about the microbes and he loves drinking beer." I go, "Is Mark an alcoholic?" He said, "Well, no. Why would you ask that question?" I go, "Why would you put it in there? What are we supposed to do with that?" Said, "Unless Mark having some sort of uh proclivity towards drinking beer and making his own beer directly impacts our risk tolerance with him and his financial management and how he processes credit cards. I don't actually care about this piece of information. And it was I don't even want to say an aha moment because I've ran into this situation so many times with personas where we include these pieces of information that really have no value. And what they do is they dirty and they muddle these other pieces of information that are are widely important. And that's why I hate personas so much. And I want to make them better. And then lastly, you get this quote, right? I want to experience more of the things I missed growing up. up. I want my partner and cats to feel financially secure. I want to travel. I want to make up quotes of people that that they didn't say. I want to make up quotes about things that didn't actually happen. And I see this often. And so, if you've used a persona before and you see any of these very trademark statements or things, right? The stock photography, the fake name, um the quote that doesn't it wasn't real, and the script font that looks like somebody wrote it. Um you can probably deeply understand why I really don't like personas, especially as a researcher. because it doesn't actually tell me anything. So, so what do we do, right? Um, next slide, please. Well, we understand first why people use user personas. So, I think it's important to clarify that as a researcher, I'm much more specific to the qualitative side of research and not quantitative. So, I am not a data scientist. I am not a a specialist in math. I am not a uh statistician, if you will, but I do work with large sums of qualitative data. And I love apply applying principles of quantitative to that so we can make sure we're using good clean and usable data. So personas like any type of research it's it's a type of methodology. So we need to understand why do people actually create these to begin with. And the first is that we want to build empathy and understanding. Where I challenge that as the reasoning why we would create a persona is if you need to create a fake character with a fake picture and a fake name to build empathy and understanding with your users, you probably have a narcissist or many of them somewhere in the seauite of your company. And that's an entirely different problem that user personas are not going to solve. However, when we think of the user experience space, which is what I exist in, right? I'm a UX researcher. I don't need a fake person to build empathy and understanding with my users. It's a core part of what I love about my job and why I do what I do. The next is, you know, to provide direction for design decisions. I was a designer. I was a product designer for years before I jumped into research. That was my background. It's not in research academia. I came from being a designer. I hated what I was designing and building. And so, I jumped strictly into research. And I can tell you as a designer, there's not a single persona that I've ever seen that has helped me make design decisions. The next is to communicate research findings. Well, if the research findings are sprinkled with fake pieces of information, then we already know that it's not effectively doing that. Fourth is to gain a perspective similar to the user. And this is where I think personas probably have the largest value at is that we're trying to uh cluster and pull all these different pieces of information so we can show different facets of a perspective of a user base. But I think where it really gets lost is when we start with too large of groups of information and then try to pull out personas from that. we're not really getting varying perspectives because we have too many pieces of data that don't have clear guard rails to show us what that perspective is really going to give us insight on. And then lastly, who are we designing for? So, going back to point two, I was a product designer for many years before I got into research and I don't want to speak for all designers when I say this, but I am. There is not a single designer that you've ever worked with where a persona is telling them who they're designing for. And the reasoning why is because it's too robust. It doesn't tell us what we need to know from a micro interaction or an information architecture or from a behavioral um science kind of predictability standpoint, which is what I deeply need to know as both a designer and researcher or as a developer when I'm trying to create changes within a product. Next slide. And the other reason why I deeply hate personas, especially when we assign photographs and names to them, is because it it introduces a lot of risk. And so what happens when we create kind of these fake people, is we really risk leaning too heavily on personal interpretation, which will ultimately depend on millions of factors, right? So prior work experience, um you know, personal understanding of that of that demographic or of that group or that culture. it it's also our our level of awareness of our own biases and maybe our own kind of sexism, racism, bigotry. It really creates kind of a an open landscape for all these varying opinions of how I'm perceiving that persona to come in. And one of the other times that I've given this presentation, I I showed that exact slide about Neil. And I said, based off of what you're reading, what do you think about Neil? And what was really interesting is I never said Neil's sexual orientation. All I said that was that he was married, he likes micro breweries, he likes being fashionable, and he owns a bunch of cats. And just from those pieces of information alone, people started to infer who his partner was, what, you know, gender or um sex his partner was, what the dynamics of the relationship were, um you know, and then started creating kind of assumptions and stereotypes around that. But I never introduced any of that information into the way that I created the persona. So, it really goes to show as soon as we assign a picture and a fake name as this kind of reflection point of this entire demographic or this this this base, although we're trying to be inclusive and representative, what we actually do is we open up a lot of space for um personal interpretation and bias. And so when I do personas, I really try to dive in not only to the day data, but make sure that we're removing any of these kind of areas or points where we're going to introduce what our assumptions about that persona is going to be. And so I say completely leave them off the table. Don't include pictures. Don't include names. Instead, assign something, a theme or an essence. And I'll show you how I've done that later on in the presentation. Next slide. Okay. So what do we do instead? Again, I am not a data scientist, but I've been very fortunate in my career to work with a lot of different data science and behavioral science departments. And one of the things that I love is the theoretical practice and methodology of how data science models are created. And I thought, you know, even though I work primarily in qualitative data, why would we not create personas in a very very similar way? And so that's really what I'm going to do here is kind of talk you through how I've created personas very similar to the process of a data science model given that I wasn't able to you utilize the same leverage of data that a data scientist probably would. And why I think that this is really helpful is because it's a better way to understand how different types of users are likely to interact with a product or service. Right? So, it's not giving me different perspectives of what they enjoy doing in their free time or um you know their their hobbies or their likes or their pain points in a very generic sense. What it's saying is how likely from a behavioral science interaction design user flow perspective are they they going to be to interact with this product or service? Because what they look like doesn't matter but how they behave does. Next slide please. So what you see here it's it's my left but um this kind of tree shape this is how we often see user personas started which is we try to pull all this information around our customer base and then within that we try to identify okay what are these themes and groupings and commonalities that we're seeing. The problem is is that's not anchored in anything. So what I want to challenge is if you've used user personas in the past what was the goal? How are these how are these supposed to be leveraged? Because again your product and your design and your development teams are going to have no way to leverage something if we use this very large kind of catchall net of our customer base and then try to apply information to it and say okay now translate this to make product and design decisions and so what I like to do instead is a very kind of guided on rails approach and what I say is instead of just casting a wide net almost like customer segmentation and marketing segment segmentation really think about the way that your organization is structured And if you have your teams broken up by a feature basis or a product basis or a hardware basis or even a part in the customer journey, then your user persona should reflect each one of those categories. And so what we're saying is allow the structure of the organization to directly reflect the starting point of the user persona. So what you see here on the right side is each one of those little starting bubbles was actually a product line segmentation breakdown. So within the point of sale research team that I run, we've got, you know, mobile, which is more hardware and software colllocated because what it's saying is these are members or excuse me, customers that are going to use the mobile device, meaning they're on the go. They're going to plug a little card reader into their phone and they're going to transact and they're going to keep going. And so how they're using this product from an ethnographic standpoint as well as the feature usage is going to be quite different than a brickandmortar location that has a customer-f facing display with an actual register that is you know doing both credit card and cash transactions. And so although if I were to start big, I might have this kind of fake generic customer base, but their behaviors, even though they might make the same amount of money, they might be the same age, um same same gender, same race, same demographic location, they actually don't inherently share any commonalities in the way that they're interacting with the product, which was why we start there. So when I first initially did this, I broke it up by product line segmentation and that gave me mobile. It gave me register. It gave me back office, which is really more the admin portal that's independent of a hardware. And then it gave me terminal. And it just so happens that that's how all of our product teams are are broken apart. So now I could create a persona specifically for that design, development, and product team where they could now make decisions based on the nuanced understanding of how their customer base was interacting with that product that they're working on. Next slide please. Okay, so what do we do first? Well, we're going to follow very similar processes to what you would do in creating a normal data science model. We're going to collect the data. Now, because I'm going to assume that not everybody in this audience has the ability to work with a data science team, that's totally fine. Work with the qualitative data that you have. So, when I first started, I was the first researcher that was hired to report up to the bank and run these other teams. They did not have a head of research. They didn't even have uh they had some contract researchers, but there wasn't infrastructure in terms of the type of data that I was going to need. So, I had to be really scrappy in how I pulled my data, especially on a qualitative qualitative side. So, I looked at surveys, I thought through chat bots, um support tickets, I did stakeholder interviews for for one of my personas. I think I met with 10 different stakeholders, like four different onboarding specialists, two different support specialists. I met with sales, I met with marketing, I met with designers, I met with product managers to get this really wide kind of depth and breath of understanding of how these people thought our users operated based on their personal experience interacting with them. Then what I did is I tried to kind of uh rank that against a our call our call log data. So if I have, you know, support ticket data or chatbot data, I can say this is what the internal stakeholders are saying and I can actually validate this and back this up based off the support tickets and calls that we're getting from customers coming in. And then lastly, if you have the the capabilities to look at quantitative data, I can start diving into things like Adobe Analytics, Google Analytics, Pendo, Quantum Metrics and say, do I have these behavioral interactions that are are supporting what I'm seeing and validating against these surveys as well as interviews? And anything from click rate to, you know, um, a support ticket is going to give me a pretty good understanding of how much data and information that I have available. The other thing that I love about doing this as data science models is, and I'll talk about this in later slides, is it tells you how confident you are in the persona that you're creating. So, one of the tough parts when we do really generic personas of this catchall data, I might see a really strong correlation between all these goals and pain points and behaviors, but I'm not actually confident how well that's going to translate into how I'm going to predict their behavior when they interact with the product. But when we do it this way, we can actually have a confidence based on the amount of data that's available. And so if a product manager comes to me and says,"I really want to create this X or Y feature," I can go to the persona of that product that they're working on and say, "Actually, yes, I've got information to support this notion or this idea, or no, I've got nothing." Which means we've got low problem clarity and high risk, and we need to go out and collect more data in order to better understand this problem space. And every time I continue to collect data, although it feels siloed, it actually all feeds back up into the persona because I've intentionally made them anchored to that product that we're working on. Um, the data should include information about their demographics and behaviors and motivations and goals much like you would do in a normal user persona, but the difference is again it's anchored to the product or it's anchored to the feature or it's anchored to however your business is broken up in terms of how it handles you know product and project initiatives. Slide two please or next one. Um, so the other thing that I think is really really useful is when I really started exploring how could I make personas better, I wanted to make sure that my variable attributes that I were was assigning stayed consistent every time I did a stakeholder interview or every time I was analyzing and trying trying to better understand data. So I actually took this from a nonprofit playbook around how to create user personas from for for nonprofit businesses. And one of the things that I loved that they did is they talked about the relationship between the persona and the business and they keep the language consistent every time they're doing research especially when they think it's going to apply back or feed into the persona. So the first one is true friends right these are high profitable long-term relationships and businesses will want to delight nurture and retain these customers and why this is really really important is as a business if I understand who my true friends are and then I start dialing into the behaviors that I am seeing within my primary persona those might not line up and I think often especially in design and development we don't hear those misalignments called out earlier and then we find ourselves like halfway through the product, you know, development life cycle where we're like, ooh, the person that we're designing for in our ideal state actually don't match up. And what we should have been doing in our product strategy is actually thinking through nudging behavior and thinking through how are we going to get people to shift to more of that true friends category. And by creating this language and this conversation around it, it really allows us to talk through. We might have a misalignment with who we want to be our customers and who we're actually seeing within this persona use our product and their behaviors. The second is butterflies. So they these tend to fall into that secondary persona category, which we'll I'll talk about a little bit later on. But butterflies are still highly profitable. Um but they're a transient relationship. So, I see this in my BIS or my my field all the time with our point of sale. We're really really great for like, you know, getting started businesses and momand pop shops and, you know, people who are running a hair salon out of their basement. But when you start to get to these, you know, multi-chain national type businesses, although they're profitable when we have them, they're eventually going to outgrow us. which means I need to really dial in how much bandwidth and resources I'm putting into my teams to focus on somebody that might not be active for that long. So, it's very much one of those like we'll design for them if we can and if it makes sense, but we really want to kind of dial into who is our 8020 and the personas allow us to do that. The third is barnacles. And it's one of my favorites because I was able to find an icon of a barnacle. And that just makes me happy. And it's a really funny word because barnacles are lowprofit long-term relationships. They kind of just stick to the bottom of your ship and they damage the paint and they rust it and they get scraped up on things and they're kind of just a real pain in the ass. So businesses will limit investment in these customers because there there's a limited fit between the company's offering and the customer's needs. And if I'm creating personas correctly anchored to product usage and behavior, I'm going to start to see if I've got some barnacles within that product segmentation. And then lastly, strangers. So low profit and short term, usually due to for poor fit between offerings and needs. So businesses will avoid any investment and may actively seek to lose these customers. Again, what we're doing is we're creating a conversation point and language around the persona, but our relationship to the persona and whether or not it's the relationship that we want. Next slide, please. This also goes both ways. So, in when we're talking about personas and we're looking at, you know, behaviors and pain points and demographics, etc., the relationship component is huge because it's it's a two-way conversation, right? So, if I have a primary persona and they're not fulfilling this true friends category, I want to understand how that persona is thinking of us. So there's about 13 words here which range everywhere from arranged marriage so used only because of the situation or because it is required all the way to enslavement. So involuntary relationship governed exclusively by the product's wishes or desires. This is very very useful because it it's now created a variable right for every type of relationship we think that we can have with our customer and it keeps that variable consistent as I'm comparing and contrasting across customer interviews, stakeholder interviews, etc. And now I have consistency. So I can see how these relationships morph and change not over not only over time but over product and price point and product usage. And so this is really relevant to somebody in my space because we have a lot of uh like third-party omni channels that we onboard people. So we might be recommended by a banker, we might be recommended by Elevon, we might be recommended by State Farm or Costco. And so I need to understand if that relationship coming from that channel is a good one or a bad one. And now I have the right vocabulary to be able to describe those relationships and I can see those those clusters of information as I move across from data point to data point. Next slide please. Okay. So now we've got clean and process. Right. So even though it's qualitative data, we would still want to clean and process the same way that you would with quantitative. We want to ensure that we're removing any outliers. Uh recognizing if there's information that's missing that we need to continue to go out and collect that there's huge gaps. Maybe I've got a lot of strong confidence in one area around, you know, behaviors and product usage, but I'm totally missing their goals and I'm not understanding their jobs to be done. And we want to do it in a format that's appropriate to to analyze and synthesize. So with qualitative data, one of the best things that you can do is um affinity mapping. I've sat through interviews and I'm putting pain points in all these different buckets on different colored sticky notes, putting them all over my wall and saying, "Okay, this is where I'm seeing really clear clusters and concentrations of data and here's where I have huge gaps and I've got no idea and I need to go back to the drawing board." It's no different than what you would do in a real data science model where you're plotting out all these data points and maybe you're looking at you know distance between one data point to another or concentration of data points or um you know mapping from from the core you know centricity of of the the data point cluster. We can do this with qualitative data and affinity mapping. The only clear difference that you're going to see between doing like a true data science model and more of the theoretical kind of approach and practice of it is I'm not going to be able to come out and say I have a 97% confidence in this or this is the confidence interval that I'm looking at from from my midpoint out. I don't have that right because I'm using best practices of data science modeling without actually doing data science modeling. And so what we do instead is we just use adjectives. We say okay this is qualitative data so we'll use qualitative descriptors. I've got a high, medium, or low confidence in the way that this user persona was created. And one of the beautiful things that I think I really love about the way that this is done is if I've got a low confidence, it encourages more research. It helps people come to my team and say, "Wow, we really need you. We need we need more research. We looked at your persona and we've got nothing to kind of back up this direction we want to take. How can we conduct more research that continues to feed into this persona to, you know, elevate it next to a medium or a high uh confidence interval before we choose to kind of move forward with the direction that we want to take? And with personas, at least the way that I want to do them is like data science models, they get trained and they get trained over time and they become stronger and better and more robust. in personas that I've seen in the past, what's really difficult about them is that they're one and done and it feels like stakeholders sort of create them and then we like pat ourselves on the back and we say, "Look at this great persona that we created and then nobody knows how to use it." And by the time it actually, you know, percolates downwards towards design and development, it's outdated and it's expired because it was stagnant. It was created as this point in time capture and then nobody went back to it and then two years later we've got to completely redo the personas. So when you treat it like a model, there's constantly information feeding into it that is making it stronger and really more robust. Um the other thing I want to say kind of about confidence intervals and why it's good to apply to personas is because it's going to tell us how good our estimate is, which is not something that I feel that I've gotten from a lot of personas in the past. I don't really know based off of what I'm seeing and what I'm reading how my insights are going to translate to a good, you know, estimate. And so the less data and more outliers for a particular persona, the more caution that's required when using that estimate. And this is huge because I joke with my team all the time that your researchers first, librarians second, and lawyers third. Never never kind of commit to something without clearly expressing its limitations. And all forms of research and research methodologies have limitations. And so by doing it this way, we can clearly advocate and speak to the limitations of this methodology and the research that we're about to present because they're an important reminder that all research methodologies have limitations and now we can communicate that to our stakeholders and the people that are going to be leveraging these documents. Um, next slide please. So exploratory data analysts, right? So after data is cleaned and ready, you can start to understand the data and identify patterns and trends. Um, so when you're moving it, you know, from affinity mapping, now we're actually starting to put it into what looks like a stereotypical user persona. Um, the only difference here is you'll see that I have a a box for the relationship. I want to understand the themes of the relationship to persona and their relationship to us. We've got attitudes and behaviors, goals and pain points, which are pretty generic and standard for a user persona, but now we've got it anchored to primary usage. So, back to my earlier example where I was saying, you know, I could have a customer who is a food truck owner and one, you know, multiple food truck owners that are, you know, uh, in a similar location, let's say the Midwest, and they make, you know, under a half a million dollars a year, right? In a generic persona or a traditional one, I'd say, "Oh, that's my persona. This is their pain point. They're trying to grow their business and pass it on to their kids, and maybe they want a second food truck to open up." Again, from a product and design perspective, I can't do anything with that. But if I anchor it down to food truck owners are more likely to use terminals or they're more likely to use the mobile point of sale, now I can anchor it to usage, not only user flows and customer journeys, but also into feature usage and then drill down that way. So again, we're trying to predict behavior not just generically, but with their interaction with the product, app, you know, feature or service. And so by creating an a point for us to analyze that data, I now have something that can be widely more used by product development and design. Next slide, please. Okay, so this is where we're we can kind of branch off in two different directions, right? If you have a data science team that you could work with, you're going to what I believe would be using clustering techniques. Um, if you don't, what you're going to sort of see is that based off of usage and the amount of data that you can gather, you're you're going to start to see these focal and secondary personas emerge. And you might even get a tertiary persona. But the focal persona that you'll see emerge, right? This is this kind of like visual aspect of the clustering. It's the primary user of the product who is the main focus. And ideally, we want these to be those true friends. And we will optimize the design for this persona group. So now, not only are we taking the personas to help impact product design, but we're also helping create conversation around acceptance criteria and scoping. Who are we designing for and who are we not designing for? And this is the same thing with secondary, right? So a persona group that also uses the product but are not the main focus. So we're going to try to design for them and satisfy this satisfy this group, excuse me, if we can. If we can. We don't always have the capability to do that, especially when you think about bandwidth and time and resources. And so when we're using this personas, it's helping us start the dialogue around what are my edge cases, what is my primary use case, and what is out of scope for this project because we simply don't have the appetite to account for all these different personas. It also gives us a a way to start the conversation around who is unimportant, right? those strangers or those barnacles, the low priority user, including infrequent, these user types will fall outside of the norm and can use the product incorrect incorrectly or introduce greater levels of human error. This is really important to understand because when I'm looking at clustering and I'm looking at all my data points, I can now understand I've got my usage data and now this is actually deeply contrasting for my my call logs and my support logs. Well, why? Because the vocal majority does not reflect the silent minority. And so now I have an understanding if you know all these calls that are coming in about users wanting this specific thing that's not lining up with the person's behaviors that I'm seeing. I can now start to identify those are just the people that were maybe unimportant. Those were the people that were actually probably misaligned with the product or weren't using it correctly. Now that could be something around usability, discoverability, um you know you know help help boxes or or you know info tabs, but that's a different conversation, right? But now we've got those pieces that help us break it apart. We can also start to understand affected. So this is really huge in my line of business because we have business owners and then we have the people that actually need to use the product. So I might be a business owner and I spend most of my time on the administrative side, inventory, invoicing, uh employee management, but it's my front of house and my kitchen staff that are using the point of sales software in and out. So any decisions that I make, I need to understand are they affected by it or are they the primary user. My kitchen staff might be the primary user for um something like a kitchen printer but the business owner is affected by it. And now I can understand that within the persona and say is the focal the actual person using it or is the primary the business owner. And then lastly we've got excl exclusionary. Right? So, what we're doing here is we're saying this is what's out of scope because we're not seeing this align with the core cluster of behaviors that we're seeing within this persona. Um, next slide, please. So, we need we need to build the model, right? Um, in the way that I think about this, again, I'm not a data scientist, so I don't want to say that this is the most expert approach, but it's it's a divisive approach to hierarchal clustering, right? because you've got this primary, this secondary, this tertiary, and then we're saying things that we we are deeming as exclusionary. And so this top-down approach is where we consider that all the data points belong to one larger cluster, and we try and divide that data into smaller groups based on either termination logic or basically a point beyond which we think that it can no longer be divided. And so that's why having these kind of categories or these buckets of pain points and behaviors and product usage really kind of help us narrow down. You might find if you try to leverage this approach that you have, you know, large scale sums of both qualitative and quantitative data and it can actually be applied to, you know, larger scale data science modeling or different types of data science models, which I definitely encourage you to do. Um, but if you're trying to just like apply this in a much smaller sense and and you're trying to do with what you work with, do an onrails guided approach. It's basically constraintbased supervised clustering is sort of the the the the parallel to it. But what we're doing is we're taking our information and we're saying we know it's starting within this kind of vertical within this product usage. And now I can say based off of this hierarchy, I've got primary, secondary, and tertiary. and then everything that I want to exclude out of that because at the end of the day the the real goal here is how can I predict what I think that this customer base is going to do specifically anchored to this product. Now data science models try to you know replicate the human decision-m process right so if I have the ability to do that I might look at things like um supervised machine learning techniques or decision trees or random forests or neural networks to predict user behavior and actually be able to create like a machine learning model to be able to do that. However, if I don't have those capabilities and I don't work with the data science team, what I'm trying to do is take all this internal tribal knowledge and say, I am making a prediction that is not just based off of gut instinct, which we see a lot in product, especially from product managers. And what we're doing instead is saying, I am making a prediction based off of a behavior, and here's all the endpoints of data that are allowing me to feel this way, and here's how confident I think that is benchmarked against the information that I have within this cluster. And so the awesome thing about this is we can actually we can train we can we can theoretically train even if you weren't using a true data science model. Um so so next slide please. So this is what our mobile focal looked like. Um as you'll notice I don't have a single picture of a fake person nor do I have a name but what I have instead is I have an essence or a theme that directly captures the the behavioral nuances of that persona. So for mobile, as I mentioned, it's like plug into your phone, the app or software is already on there, and you're just swiping in your credit card. So what we started to see about this as the focal persona is this is a oneperson team. These are people that do not have a plethora of staff. It's usually just them running their business. And then I was able to pull a quote from support that directly helps support and validate this theme or this essence, which is Brenda from support goes, they don't really get personal with us. They just want to get their business going. like, "Yeah, duh. That makes sense." Because they don't have extra hands to help them make these calls and do these things. So, they want to be able This is the the persona type that's going to be the most likely to try to troubleshoot things on their own before they have to call in to support. And then the other aspect that I added here is who are the businesses that are most like this persona within our customer base. So, we should be able to link this persona to real customers, real people, not fake characters with fake pictures and fake businesses, real businesses. So, if I see something and I'm like, I have a really strong confidence that moving forward with this feature or this redesign or this product initiative, but I want to kind of double check and dive a little bit deeper. Now, I've got real businesses within my customer base that I can kind of validate this against and go do moderated interviews or send out a survey to. And so the more customers that you have that you can say most like the stronger your persona is going to be because we're linking it to real businesses and real people. Then of course you've got the demographics. So we noticed that service industry out of our three core you know verticals service um retail and restaurant. It was predominantly service. Uh we saw that they made you know less than $100,000 a year you know less than three employees. So those were core demographic clusters that we saw that most of these personas or this focal persona had. Then we dive into the relationships, right? You've got arranged marriage there, the mostly true friends and the reasoning behind it. We've got primary usage and then we dive into attitudes, behaviors, goals, and pain points specifically anchored not to their general generic life, but specifically anchored to their product usage. And what's great about this is that when we did this exercise, what it taught us is we actually have this really unique secondary persona. And that is people that fall into seasonalbased businesses. So when we looked at mobile, we're like, we are not just seeing companies that use service. We have this really weird secondary persona that's emerging, which is people that are really active users on the mobile application, but only for certain points in time. We're like, "Wow, these are seasonal individuals." So people that do landscaping, people that do uh like Christmas light installs during like the winter season, um people who, you know, only do like uh seasonal food truck fairs at festivals. So when they are using the app, they're doing high transaction volumes and they're using it every day and they're in and out, but then outside of that, they're not really doing it, which means that there's other areas that they need to go to maintain their business outside of when they're doing their seasonal work. We wouldn't have been able to determine that secondary persona had we not gone through this exercise of pulling all this information and clustering and understanding. And so what it told us is when we're designing for mobile, we have to account for the fact that there might be some different use cases or variations in in feature and in feature adoption because of the secondary persona that's seasonal and their needs and pain points are slightly different from from the the primary. Um, next slide please. So so validate and test. Um, this part is my favorite, right? Because what we're saying is every time we do this, we can actually see whether or not we have the data and the persona to support an assumption. So we did this exercise with all of our product managers and I said, "Bring something to me that your team is thinking about working on right now because it needs to be validated and tested." And so one of the product managers came to me and she said, "Mobile users," which was one of the personas we felt the most confident with, we had the most data. She said, "Mobile users would like the ability to attach images and other documents to their invoices so that their customers can understand what they are paying for when viewing and making a payment on the invoice." Said, "Okay, where are you getting this from?" Well, we we've heard it from support logs. We go in, we look at the support logs, and we say, "Yep, we're seeing that in and the data and the way that we've clustered it." But the interesting point that helped validate why this was a good direction is when we looked at our persona around our mobile customer interviews and stakeholder interviews. One of the things that kept coming up was people said, you know, this mobile app is actually the only online presence that these small business owners have, meaning they don't have e-commerce. They don't necessarily have a Facebook page. So, they are using their their invoicing or their their point of sale application as kind of their online presence. So now we actually have support for this idea of they need im images to attach to their invoice because that's how they're showing their product catalog. There isn't actually another online presence to support that. And then as we dive deeper into the persona, there was these other little data points within that that sheet that said, "Yep, we're understanding the need to attach images." So our confidence based off of this assumption is actually much higher because we have information within the persona to validate it. Now I can work with my product manager to say, "Hey, we actually have pretty high problem clarity and lower risk. We can design and then test in the live environment or you know what, we've got high problem clarity but high risk. Let's spend a lot of time doing validation and testing and iterative design or usability testing before we launch this." But being being able to use the persona and to train it against product manager assumptions helps me as a researcher identify what are my next steps in my research plan and what methodology should I choose so that I can better answer these questions. And so what we're doing here is that we can kind of train against what the assumption is against the set of data. And if we start to see a huge breakoff, right, like they're not lining up, what that tells me is to go back to my product leader or my stakeholder and say, "You do not have enough information to move forward with this assumption. It's not validated. It's an assumption. We either need to do more discovery research, whether that be generative or evaluative. We need to start collecting data now to help support like our understanding of these behaviors and interactions within the product. But it allows me to press pause when stakeholders want to move forward because what I'm saying is I'm trying to train this set against our benchmark and it is not lining up which means it is breaking that confidence that we're seeing and so I need to now go get more data to feed back into the persona so that we're understanding kind of what this 360 view is. Now keep in mind that building your persona is an iterative process which is why I love using like data science methodology to apply here. It's not a oneanddone. Um, it'll likely need to be refined and updated over time as more data is collected and analyzed and you might need to push out data as it becomes old and kind of retired and it might not no long it might it may no longer apply to your customer base. But what I think is great about this is that the persona is supporting or not supporting, right? It's validating or not validating an assumption that is being made by a stakeholder or product owner. And we have this 360 capture specific to that product se segmentation and product usage to let us know what our starting point is as researchers. Um, next slide. I think that might be my next my last one. Yes, thank you. So, um, I do I think we have about 10 minutes for questions. Again, I want to reiterate that I'm not a data scientist. So, if there's anything in this that was said that you deeply disagree with, please let me know. Um, but I did create this based off of my experience working with data science teams and I just loved the way that they approached data and clustering and found it very very useful and how I approached um, creating user personas at our company. Okay, I'm going to stop sharing and then let's look at some Q&As's. Ingrid is asking, "When there are different personas for different product teams, how do we avoid teams going in very different strategic directions? Yes. Okay. Well, so the great thing about these is this is your this is your conversation point. Like you need to be having those conversations. So what I love about kind of using the personas is it gave me the verbiage that I needed to either advocate for us doing more research or us getting product alignment. So if you start to see these really different directions, that's going to allow you to come in and say, "Okay, if we have features or aspects that are shared amongst products, which we do, right? There's certain features that our mobile and our register both utilize but the usage of it is quite different. It gives us that that conversation around our appetite which is do we need to try to create a feature or a product that is a baseline you know minimum viable product that can do most of the needs for both or are these differences distinct enough that we actually need to argue and advocate for two separate features or feature flagging for how this aspect is going to be used. So that's what the personas help identify is like if you start to see like completely different usage on invoicing for mobile versus invoicing on register that is alarming like we need to be talking about that and so it's not going to solve that problem. What it's going to do is it's going to shed light on it and really act as that catalyst towards a conversation of what are we working on and why and do we have an understanding of of our our customer base and who we want to be designing for. Right? Because going back to that conversation around true friends versus butterflies, why those are integrated into the personas is because it tells us are we designing for the right customer base and where we want our customer base to either grow to or move towards. Okay. And Karen asks, uh, could you please go into more detail on how to determine a low, medium, or high confidence level from an affinity map, especially when you only have qual data? Yes. And so the best way to do this is just like how much data were you able to gather. So for so for me with the mobile because it was a newer product um not only was I able to interview like 10 to 15 stakeholders right so support onboarding specialists all these people that work directly with the customer um and I had support logs the other thing that I had is our customer success team had about 30 different customer interviews with customers doing persona interviews. So I felt very confident in the information that I was getting back on mobile because not only did I had quantitative data from like an analytic standpoint, I had all these stakeholder interviews of people that worked directly with those customers plus I had customer interviews. Now, there was another one um register where I didn't have any customer interviews and I was like, okay, in order for us to increase this confidence around this persona, I need to go out and gather about 15 to 30 moderated like moderated user persona interviews where I'm going through and I'm asking these questions. I made sure the script that I had was the same across all interviews. Um, but I I needed to go out and collect those because we didn't actually have any direct primary research, you know, from the mouth of the customer. And so I was like, okay, well, this is all internal stakeholder information. And that makes me really, really nervous because we have a biased perception around our customers and their behaviors because we work here and I now need to go create more robust data by going out and collecting these customer interviews. So, it's really on the amount of data and I think the um variation in data, right? Like if you've got a ton of data in analytics, but you've got nothing else, right? So, it's primarily quantitative, but you've got no qualitative data, you're not going to really have a strong gut feeling on what's happening here. But if you've got tons of stakeholder interviews and support log data and qualitative data and customer interviews and usability testing done, that's really going to lead to a stronger user persona. So, it's like how much data do you have and how much data can you go get? And again, it's a really really great conversation piece to say we don't know anything about this customer base and we're designing for them. We're we're pushing out new features and you know, development's just whipping things out and we don't actually have a hard a strong confidence that that we're doing this correctly. And and I found the way that my team leverages it is it makes them feel really empowered to give push back. They're like, "No, we don't have strong confidence in what we're doing. you can go ahead and build this, but you're not going to hear our team support it. And it really gave them like that tool in their toolbox that they needed to really push back and ask for more research. Excellent. And then um a question from Doug on YouTube. He said, well, comment and a question. Great presentation. So much detail and thought in your process. Um do you ever talk to consumers about their payment experience since they're the ones who ultimately your customers are serving? Yes. Yes. Okay. Oh my gosh, this is such a great question. And that's why we have it in that hierarchal cluster category where it's like primary, secondary, you can even have tertiary, and then you've got affected, and then you've got exclusionary. It's because we're trying to understand all the different interaction points with with the product. And so what we understand is like for example, and that's why I split it up by product line, right? Because if I'm an admin and I own my business, I'm spending a ton of time understanding employee roles and permissions and invoicing and inventory. But if I have a register device, which is a different hardware and a different software, I've got a customerf facing display. There's tons of testing that I need to understand around the customerf facing display. And you can even go as far as creating separate personas, one for the backend and one for the front end. backend, meaning the the restaurant worker that's utilized in the customerf facing display and then an entirely different persona category around the customer on the paying end has to utilize it. And we've even gone as far as wanting to do two separate primary, secondary, tertiary personas, one for the user of the product and one for the customer on the paying end because we found that there was enough data to support like the separation into two like persona categories. And one last question uh since we have about four minutes. Um Ingren also had a comment and a and a another question. She said, "I also personally really chafe at traditional personas with flowery fake details, but I've lived in organizations that are tied into these personas, especially for marketing and creative purposes. What are some tips on transitioning an entire organization along from incumbent personas?" Oh gosh. Okay. I would not recommend for most people to take the path that I do, which is I am a I am an I am so to the point like I just call things out in meetings. Um I think I really rubbed people the wrong way when I made my is Mark an alcoholic comment because it was in a very big stakeholder meeting. It did work out. Uh fortunately everyone was like well what would you do instead? And I was like oh let me let me tell you more about what I would do instead. But what I find is see if people are leveraging it, right? So if you're a researcher, do research. Who's leveraging these personas? And if you start to see that nobody is, start there and interview and ask them why. Like why don't you use personas? What would you want from personas instead? That was one of the first things that I did when I was trying to think about how to organize the playbook. I went and met with dev development and then I met went and met with design and then I went and met with product managers and I was like what are each one of your needs from a persona and how is the current state persona's not not meeting that need and that really helped kind of tell me where I needed to start because I was able to create something that I knew was going to be adopted in a very grassroots way. So if you don't want to be uh abrasive and aggressive in how you're going to get something done, do it in a grassroots manner. So I promise you those personas are getting created and not a single person in your org is actually utilizing them. So go to the people that actually need them and figure out what they want and then design it design it backwards. Okay, great. Thank you so much for for that presentation.