User Inclusion: Focus on the User as You Develop Your Product

Valencia Bey at UXDX Community: USA Online Series. Video: https://youtu.be/ttBInNCspb4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why product design needs user research

[00:00:00] Hello, I'm Valencia Bey, and I have been a UX researcher, a UX practitioner, for about 22 years. I got into the field as a technical writer, and got into the field before it was even called UX. So I'm excited to share this information with you today, based on my years of experience working with startups, working B2B, B2C, in every situation, for corporations and then on my own. In every environment I've worked in, there has been some level of omission or oversight when it comes to user research.

[00:00:40] So I want to talk today about the importance of focusing on the users as you develop the product, and the reasons why. My talk is a condensed talk, so feel free to reach out to me on LinkedIn or through the Slack channel they're going to share with you for additional information. But I've summarized some of the highlights there for research, and so we can get started.

[00:01:06] Product design should always include users in the research. It seems obvious, but many times it's omitted, because they say there's no time, we don't have anyone to do it. How does this differ from marketing research? We have our quantitative data, we have our analytics; why do we need user research? Well, we need user research because the product team has great ideas. Typically the product team is a creative team of individuals who really, really know their stuff, and they're excited about developing the product. They have a lot of knowledge, but they're too close. As a product team, we're often too close to the product and to the rest; we're just too close.

[00:01:46] So we need someone to give us a fresh perspective and a more accurate perspective, because analytics and data will tell one story, and our ideas are one story, but we're typically focused on one thing, many times monetization. Of course, because if you sell the product you make money, and of course that's the reason why we exist: sales, marketing and product, we're selling a product. But research is important because we have to understand what we're developing and why we're developing it, so that it can really meet the needs of the end user. Some ways we can gather feedback from the user: surveys, one-on-one interviews, reviewing analytics, usability testing, and then focus groups.

Setting priorities and checking assumptions early

[00:02:32] Research is critical, again, because we have business needs and then we have the user needs. Sometimes those things align, sometimes those things don't. So it helps us to set priorities. Those larger projects are sometimes planned; we have the product roadmap, as was mentioned in the last talk. So how do we prioritize those things? Where should the money go? What are we developing, and why? What should our focus be? That's one way research can help. We can help set those priorities by talking to users, gathering feedback, looking at analytics and painting the whole picture for the product team, to say: okay, this is why we need this, and this is going to meet this need. Or this particular feature or this particular project should be backlogged, because it won't exactly meet all of our needs at this time. Those are some of the decisions that user research can help weigh in on.

[00:03:37] Another reason why it's so important: ideally you would gather user perspective before planning a project. That's not always possible, because you may not have the personnel, you may not have the bandwidth, you may not have the funding. And you may think, okay, we're in a time crunch, we want to get this launched within six months. It's always still a good idea to do some kind of user research. Just take two to three weeks to do user research, whether it's a quick survey, focus groups or one-on-one interviews, and I'll get into those a little bit later.

[00:04:21] It's really important to get that user feedback, to help either vet the direction, or help the product team understand: we need to pivot, we need to shift, because we made this assumption, and now we're looking at the data and the research and realizing there's something we're missing, or something just isn't aligning. So let's take a moment and really talk to users and understand what users need. That saves a lot of time and a lot of effort and a lot of money as you move forward with the project, because you have some things that may be assumptions, and those can be straightened out initially, before you get into the very expensive process of development.

[00:05:06] And understanding the journey doesn't require a lot of effort. It's really about talking to users, understanding their needs, and designing the product to meet their needs.

Research at every phase

[00:05:31] Research can be conducted at any phase. Once again, ideally feedback would be gathered when the idea is just a seed. But even when you get to the design phase, where you're doing the wireframes and mocking things up in Figma or Mural or whatever you use, you can put it in front of users. Internal users are fine, but it's really good to go out and talk to the people who are your target audience. For example, if you're developing a new app for diabetes management or something, go out to people who use their phones to track their symptoms. It's really simple: go out, talk to them, see if that product meets their needs and see how they use the product.

[00:06:24] It can be really eye-opening just to watch someone use the product and see where they may struggle, because we may make certain assumptions and say, okay, this is a best practice. But in that early design phase, when you're conducting research and watching people use the application, or you set up a remote session, you can also do it remotely, when you see the heat map, or see where they drop off, and read their feedback, it's really interesting to see what people really think of this great idea you have. Sometimes it really turns out to be a great idea and it's validated. Other times it's like, oh, they're struggling here; maybe we could create a different experience, or take another look at this experience to make it more user friendly.

[00:07:10] So research in the design phase is important, and then during development, just to be sure you're on task and things work the way they should, you can do usability testing. And then there's also value in post-launch. All right, so we've built this thing. We've done some user testing, or even if you haven't done any user testing at all, you didn't have the bandwidth, you can always come in and conduct a usability test, or just send out a survey to people and ask them about the features and the functionality. User feedback is very important as we iterate the design. Once a product is launched, that's really not the end; we know that. There may be additional phases, there may be updates and things like that. So you can really conduct research at any phase to improve your product design.

[00:08:09] And the benefits of user focus, again: it helps you set priorities, you can design a product that meets real user needs, and, more importantly, understanding and empathizing with users.

Quantitative shows the what, qualitative shows the why

[00:08:22] You have quantitative and you have qualitative data. Quantitative is the analytics; we might have surveys, we might have other data from the marketing team and sales team. We're looking at those things and saying, hey, this is a great idea, we should take a look at developing XYZ. That's great, but the quantitative data shows us the what. The why is the qualitative.

[00:08:57] Sometimes, when I've done research projects through the years, we've done a survey and made assumptions based on the survey and what we think the needs are, and then we'll do a deeper dive with qualitative research, where we'll have a focus group and some one-on-one interviews. Sometimes the results are consistent, but sometimes they're different. For example, we might want to understand why a user isn't engaging with a certain feature of the site that we thought was just awesome. Looking at the survey data, they say they like it, they say they want it. Looking at the analytics data, yeah, they're engaging with it, but they're dropping off right here.

[00:09:43] So in the qualitative interviews, you go to the focus group, you talk to people and ask them about the overall design, one-on-ones and a focus group, and they may say something like, "You know what, I just didn't like the choices. The content I was looking for, I didn't find it, and that's why I dropped off." Well, we wouldn't have known that had we just gone with the quantitative. The qualitative lets us know: okay, the content you're looking for wasn't there. What are you looking for, and why are you looking for it? And that opens up a whole new world of possibility to meet the user's needs.

[00:10:21] Whereas before you had content, you made assumptions and said, okay, this is going to work, you see from the qualitative interviews that it's not quite working because of this, and that gives you the information you need to further develop the product. It's a situation where you can just create the content they're looking for, create a logical navigation path and make it easy for them to find the content. That improves usability, that helps with retention, that helps with all of the metrics that can help us to monetize our products.

[00:10:55] And it also helps us to empathize with the user. Sometimes we go to sites as UX professionals and we're like, "Who thought of this? Who thought this was a good idea?" And it could sometimes be a frustrating experience. If we do the qualitative, the focus groups and the one-on-ones, and we watch them use it or we ask them questions, we can gain a deeper understanding of their experience, and we can empathize, saying: oh gosh, okay, you're right, you're right. We're going to give you this information, or we're going to clarify this navigation path, or we're going to do something to enhance the usability of this product. And we're doing it for the benefit of the end user.

From empathy to compassion

[00:11:44] So again, user interviews can help us to understand our audience on a deeper level, and that is really important. There's a thought going around in user research, in research in general, where we talk about going from empathy to compassion. Empathy is understanding what your user needs. We know they need easy navigation, they need content they can connect with. If they connect with it, they'll engage with it. And if they're looking specifically for information to meet a specific need, we're going to present that information in a way that makes sense to them. Understanding what the real need is helps us to get that empathy.

[00:12:34] From there we can move to compassion to develop the product, because compassion helps us to take action on the empathy. It's great to empathize and to understand, but then what are we going to do about it? How are we going to change? Will our view change based on the empathy and then the compassion? I'm developing empathy as I'm developing this product, and I'm really feeling the users. I'm understanding the user need and I'm really empathetic. I'm saying, oh yeah, they really do need to do this at this point, or they need this at that point. The compassion goes a little bit deeper and says: wait a minute, why are they needing this, and how can we make it really fit their mental model?

[00:13:24] So really taking a step back and saying, we're not just designing this, we're not just feeling. The compassionate part says: all right, if this person is in this situation... I've done a lot of medical research, with people who have chronic conditions or terminal conditions. How are they going to use the tools we're developing for them if they have MS, for example, and let's say they can't really use their phone, or rheumatoid arthritis, and they can't use their phone? With empathy you can feel for someone. But the compassion says: oh, wait a minute, maybe we should make these buttons a little bigger. Maybe, instead of organizing the content this way, the content should be organized this way. Maybe the sign-up process can be a little simpler, to accommodate those who may experience fatigue.

[00:14:30] That's very important, but you won't get that from quantitative data. You won't get that from looking at analytics, you won't get that from looking at marketing research data, you won't get that from a survey. The only way you can have that empathy and that compassion and get that information is to do the user interviews and the focus groups. It's a very important thing to really understand your user: not just how they use it, but why they use it, and then the emotions and the motivation behind their usage.

Design exploration and personas

[00:15:11] Another research tool is design exploration: placing designs in front of a focus group. You don't even need a lot of users. You don't need 25 users, or even eight. You can do as few as five users and they can give you the needed feedback. So get a group of five users together and say, "Okay, what do you think about this? What do you think about that?" And just watch them, see where they drop off, see what they're interested in, ask them questions. That will allow the design team to explore ideas and iterate prior to development. Because sometimes stakeholders have one idea, and then marketing has another, and then product has another, so we have to really align, and this quick design exploration will help the team align on the design focus.

[00:15:56] And last but not least, personas. Now, you may be thinking, how is a persona going to help with this? Well, the persona is actually very important, because it helps with that empathy. It helps you to really understand your user, and also in different use cases. Going back to the example a couple of slides ago: someone with rheumatoid arthritis, how are they going to use their phone, or their device, to engage with your content or your product? Once you have talked to several of the folks who have rheumatoid arthritis and you've watched them, you can create a persona.

[00:16:37] That helps the product team to say: okay, so Lisa, in this situation, it's late at night and she's looking for information. Here's another use case: Lisa's at her doctor's office. She wants to know some of the terminology the doctor is using; the doctor isn't explaining it quite well. So maybe she's going to use her phone, and she's on your site looking for information. That helps the product team to really orient themselves to the real user needs. What are the use cases, what are the scenarios? Those scenarios are based on the user research. As we're talking to people, we're getting their stories, we're getting their background. In this case, for a medical situation, they're looking for diagnosis and treatment information. So how can we meet that need? The personas really bring that qualitative data to life.

[00:17:38] I just gave an example of a static persona. There are also living personas. With living personas, typically, we as researchers will video our participants and use some of those videos internally, taking snippets from the story where someone talks about their experience with something, so we give their real story. That's what's called a living persona, and it really does help with empathy. It helps with compassion, because you can hear the person, you can see the person, and you can say, "Oh my goodness." You can put yourself in their shoes and understand what they're feeling. So when you go to design the product, you can say, "I don't think that'll work for this person because of XYZ, and I think this will work better because of this," something you heard, something that resonated with you. That's the reason why personas are important: really bringing that qualitative data to life.

[00:18:33] All right, that is the condensed version of my presentation. I tried to make it short, knowing I only had half an hour. If anyone has any questions, I can take those.

Q&A

[00:18:45] Host: Great, thank you very much, Valencia. That was really interesting. There are a couple of questions coming in, so people are obviously engaging with the content, and I'll just pass them on to you. The first one's from Sean. He's saying nobody wants to approve post-launch research, because people have moved on to the next item on the roadmap. So how do you try to convince people of the value? Because, as you mentioned, there are multiple places where you do research. What's the value of post-launch research when everybody else seems to have moved on to the next shiny thing?

[00:19:24] Valencia: Well, if there's been no research done on the product at all, post-launch research is valuable just to get an idea of how effective the product is. You can set some metrics and then measure those, you can take a look at analytics, and you can create a research plan, perhaps something as simple as a survey, to see how effective the product is and see if people are using it the way it was intended, if there is a desire for that. It's not necessary, but that's one way to do it. And if no research has been done, you can build a case to say: okay, let's measure this and measure its effectiveness.

[00:20:04] Now, even though everyone else has moved on to the next shiny thing, yes, but the next shiny thing could be connected to that initial project, so you can build a case for that if they're connected. If they're not connected, then you can just say, "All right, I just want to do some post-launch research to understand if it's really working." And it doesn't have to be one-on-one interviews. It could be, again, a survey. You can take a look at analytics and build a survey off of what you see there to get more information.

[00:20:37] Host: Great, I hope that answered your question. We have another one, and she was saying the living persona is a great idea, but how do you avoid ending up with a persona of one? To elaborate a bit: making sure your persona is representative, rather than being just a single customer.

[00:21:01] Valencia: Well, the living persona is actually a persona of one. The static persona is typically an aggregate of different people in different scenarios, but the living persona really is a persona of one. It really creates empathy, and I would say it works only in certain situations. For example, I've done a lot of medical research, and when we talk about medical research, we really have to think about the end user, their condition, and how things impact them directly. So the living persona in my work is very important, because we get to see one person's experience. We get to understand their diagnosis, their treatment and their emotions, and it really resonates with the product teams, because they say, "Oh my goodness, I didn't realize that's what they had to go through day to day." So the living persona, the video persona, is really a persona of one. The regular persona, the static persona, you can create from different scenarios, different situations and different interviews, and just create that one composite.

[00:22:16] Host: Right, so really you need the two, then, I guess, to make sure you're not going very specific on an individual person, and making sure there is breadth.

[00:22:26] Valencia: Yeah, yes. If you don't need to go deep, of course, just use a static persona, and you can always use videos to bring it out. But the living persona is designed to be focused on a single user and do a deep dive into that single user's experience.

[00:22:49] Host: Great. Just checking, I don't think there are any more questions coming in. So thank you very much, Valencia. I really enjoyed that talk, and there were a few questions coming in from the audience, so I'm hoping you enjoyed it out there as well. Thank you very much, Valencia, for sharing your story.

[00:23:08] Valencia: Thank you for the invitation.