Lessons

Lesson Info

Personas

In this video we're going to talk about personas. Which is one of the most effective ways to synthesize. So you've gone out, you've done these interviews, you've looked at the site, you've looked at all the accompanying materials. At this point solutions will start to be forming in your head. But how do you bridge that gap between the research and what you actually need to build? And how do you focus all of this research that you've done into something you can work with on a daily basis? And the answer to that is personas. Personas are fictitious, yet realistic and detailed descriptions of the users of your product. And what that basically means is you take the all of this research that you've done. You'll automatically identify some trends. Like there's a lot of people in this age bracket. There's a lot of people with this type of habit. And this type of usage pattern. So you take these patterns and you create that you gained from your research and then you create a profile of a perso...

n. This person is not real, but it's based on real people. So you're not just pulling personas our of your fingers, you're basing it on research and the point of this, like how can fake users help design a real product, right? It look me a long time to understand the point of personas. In college, all through college, I didn't get it. But what they do is- there's a couple things that they do. And personas are particularly useful the bigger the project you're working on and the more people that are involved. Because instead of saying, hey, in this one study that we did we found out that some of the users that item X was really important to them, instead you have something concrete. You can say, hey, we know this is something that would work for Matthew. So it gives your brain something to focus around. It gives the discussion something concrete to focus on. Because what'll happen if you don't do that is you'll have this concept of the user. And everyone on your team will have a different picture of who the user is. So if you're lucky it's the last customer that they saw. If you're unlucky it's someone generic like my mom. So when you're building software, that description of the user gets stretched out of different directions. If one of the product mangers is super excited about an advanced feature they'll just say, well the users are very experienced. Because that's who were targeting. Or you might be seen as a novice in other cases. Sometimes they're older, sometimes they're just out of college. The result of that is that you have a product that aims at different users at different points of the interaction. What personas do is they make the user concrete. And they help you create a consistent interface. So again, when you're creating personas though, it's important to base them on real data. Except for one exception that we'll talk about later. And they just really help focus the discussion. You have sort of like a north start that you can point towards whenever discussions start veering towards personal opinions. Another cool thing about personas is that is something that you can involve all of the team members on. It's something that you do early in the process that you can involve all of the team members on. Non-designers, engineers, product managers, everybody who might further down the road say no. You involved them early on in the building of this and then if sometime further down the road when you present them with a more concrete solution and then someone says, I really don't like that green, then you can be like yeah so I don't like that green either. But do you remember those personas that we put together as a team? Do you remember those, the ones that you agreed on, that you helped build? Then they'll be like yeah. And you'll be like yeah, so based on what we know these people that we're serving who are represented by the persona, this color is an effective way of reaching them. Creating personas early and involving, co-creating them with some of the business people, it helps you get things done more effectively down the road. It also helps avoid just in case features. Those feature where you're like that might effect 1% of the people using your product. But really aren't a case that you should be devoting a ton of your time and energy to. Some personas are just a thing that help focus a discussion. Thus the one take away here. They help focus the discussion. And they give you something real to focus on. So what do they include? Usually a name and a photo. Although photos, there's a debate about whether to include photos or not. Demographic information. In that case only add demographic information that is absolutely necessary. I'll get into that later too. Goals and needs and preferences. Those are sort of the key things that every persona includes. The format varies, but they all basically have this type of concept. Personas can look like this. They can look like the USDA example that I showed earlier. This is a persona we put together for a project that we did at glide. But you'll notice that they're all kind of similar. They all contain the same information. And the reason you add a picture and some kind of name is to give it some more tangibility. So now it's not just Jim the user but it's someone you can relate to. Personas can get really elaborate when you are working at a big company and have a lot of resources to dedicate to them. This is an example of a persona at a major company in the US. You'll notice how elaborate this is and how many little details there are and even the visual design of it is nice. And the point of that is because this is something that will be shown around the organization and used as a basis of discussion across a lot of touch points. So personally I'm not so sure if it makes sense to invest that much energy into personas because personas will vary especially when you're in a big company, you can't just have five personas for all of your products. Because the products will be so varied that it's always talking to a different audience. So you technically need to, if you were applying real UX process the way it's supposed to be applied, which almost no one does, you would have personas for each product that you're working on. But a lot of times you'll just have these super elaborate ones because they have the time to do it and there's really no rush to do anything else. So you end up with stuff like this. Or these are some personas from another big company. The take away here is what I found interesting about these is that there's sort of this table that compares them to each other and compares their needs and their usages. Super, super detailed. The impact of that, not so sure how impactful it is. But that's how elaborate personas can get when you're working in big companies. Okay, so how do we create them? There's two ways to do it. So those super elaborate personas that you saw, they're created sort of like this. You combine online research, you combine analytics on the side. You conduct workshops, you synthesize data, do interviews and it condenses in to very specific personas. But realistically, in a lot of real life scenarios you're not going to have that time. You're not going to have that budget. You're not going to have access to users like that. That's the reality of interaction design that most people don't talk about. The only book that I found that really discusses this really well, well two books- one by Robert Hoekman, Jr. Experience Required. I recommend that in my course notes too. And then Lean UX. So we're going to talk about, besides the traditional way, we're going to talk about the Lean UX way of coming up with personas. These personas aren't good, not even close to as good as the traditional ones are. But what they do is they still give your team something to focus their thoughts around. In this case you do a little bit of research. A lot of intuition. And some analytics if you have them. And you use them to create a persona hypothesis. The hypothesis is, they're also called assumption personas. Because you're really making a lot of assumptions when you're making these. But it can still work. This is something that early on in my career I did almost instinctively. I didn't know about any of this. But whenever I was designing something the first thing I would do was image a person using it. The person who I thought based on what I know about the subject matter would be most likely to use it. And I would start creating stories of how to use it around this person. Does that make sense? The assumption personas are a more formalized process of doing that thing that I was doing instinctively. So you do a little research. Wherever you can't find anything concrete you make assumptions. But the important thing here is to make those assumptions clear. Talk them through with the other team members. So that's the difference between inventing something that you just end up rolling with and having assumptions that are articulated that then later on when you're doing some more research and you've tested it with some more people you can see if those assumptions were right or wrong. And you can make adjustments. The benefit of this is the focus. Because our minds need something concrete to focus on. And even if it's not the most perfect model, it still gives you that benefit of when you're sitting in meetings giving people something more concrete to discuss than this user or that user. So again, the important thing here is to make the assumptions clear and talk them through with other team members. So if you look at this, this is basically just a pice of paper folded into four with some very basic information. It's a sketch of who you think this person is. Some basic demographics, their needs, and how you can best serve them. Here's another way of doing them. So in this case, the needs, the how to serve thing has been replaced with behaviors and beliefs. And the layout is a little bit different. But it's still the same basic idea. The way you make these is almost like a design sprint. You sit down with your team. You've done your research. And then based on that research you create as many personas as you can. You've done a little bit of research into the domain. And then you automatically start forming idea of who these people would be that would probably use this thing. And some of them are going to be wrong, some of them are going to be right. But you're going to focus on, you're going to create as many as you can of them. You just share them out. And stick them on a wall. And you'll notice that if you have like five people in a room doing this, there will be some overlap between what you made and what the person next to you made. So you discuss which one of these, which attributes in here are realistic and which ones you think make sense. And which ones aren't. And you make adjustments on the fly. Some characteristics to think about are how, again, sort of what's the context? It's another question of what's the context around this persona and what are their goals? What are they doing? How do you think they think about the product? What motivates them? And then what abilities do they have? So what you'll do is you'll take some behavioral variable. So after you've distilled your personas, you draw out, like on a big white board, you draw out a line that shows you a spectrum of skill. And then you take these personas that you've made in your team and you map them along the spectrum. They don't need to be super accurate. The general idea is just to get a just of where these personas fall. This is what it looks like in practice. Here you have years of experience, risk tolerance, education, ambition and tech savvy. And people are mapping the personas that they created along this spectrum, where they think they see them. And then after this, you take all those personas that you've made, it'll probably be like seven or eight. And you try to distill them even further into some personas that capture the essence of all of the others. When you create personas there are some dangers with them. The biggest risk that you run into when you're making personas is that they can quickly evolve into stereotypes. When you're including demographic information like age or location or something like that you want to make sure that you know exactly why you're asking for it. For example, if you're redesigning a running shoe it might be useful to know about the person's running habits. It's less interesting to now if they're also interested in fishing. Like you'll see a lot of personas that are done badly. Where there are these detailed stories about John enjoys cooking and hiking and swimming but you're actually redesigning some accounting software. So what does the cooking and the hiking and the swimming have to do with that? How is that going to help you? That sort of ties us back to one of the heuristics that we talked about earlier. How you only want to have information in there that aids in the goal. And any piece of additional information that you have in there that detracts from that goal is just distracting. So that's something to be careful of. Also, photos are an iffy topic. Because as soon as you add that photo and the name too, there is this really really- like I remember reading something where a persona, they picked a photo of a blond person and then there was like comments in the meeting room about the dumb blonde. Even though that had nothing to do with the actual persona. I tend to err on the side of just putting in an icon or a drawing instead of a real face. But you just need to be careful that you're avoiding stereotypes and avoiding your biases. You don't want demographics for demographics sake. You want to focus on the motives. What are people trying to accomplish here? Young puts it in a great way where be careful with the names and descriptions and make choices based on your team and stakeholders.