Over-Reliant, Absent, Misaligned: Troubleshooting Researcher-Stakeholder Relationships

Transcript

Ben:

Hey, I'm Ben. User researchers collaborate with a host of stakeholders. Some know a lot about our craft, others know very little. We as UXRs are most valuable to our organization when we can support this diversity and their questions. That is not always easy. In this video, Nikki Anderson is going to outline three frequent stakeholder scenarios and some questions you can ask in order to make them more manageable. By the end, you should have some new ways to advocate for UX research, clarify what its best use cases are, and strengthen your stakeholder relationships as a result. Let's check it out.

Nikki:

Okay. So the first scenario that we're going to talk about is when your stakeholder thinks that they need user research for everything. So the question is, can we do research on this? Can we do user research on this? What about on this? What about on that? So at first, and this happened to me, I was like, this is great. The stakeholder likes research they're bought into research. I don't need to convince them of anything. They want research on everything. And then I was like, oh wait, this is definitely a double edged sword because there are a few things that can happen when this stakeholder starts asking you for research on everything. The first thing is user research cannot answer everything. So what we're doing here by saying yes to our stakeholder who wants to research everything is that we're setting ourselves up for failure, which then ruins the stakeholder's expectations for what user research is and what user research can deliver, which then can have a snowball effect on them no longer requesting research and no longer liking research or no longer finding the value of research.

So when stakeholders are asking you to do research on everything, we need to really consider, is this something that qualitative user research can answer? And I have an article all about that, so please feel free to read that because that would be a series in and of itself. But we want to think very carefully and consider, when somebody asks us, okay, so can we test whether this button should be blue or red? No, we can't. Because if we were to do a usability test with seven people to test whether this button should be blue or red, first off, that's not going to be representative enough. We're not going to get a big enough sample size. Our stakeholder's going to be disappointed. We're going to feel embarrassed giving this result to people. And then everybody's going to be upset in the end. That's one scenario that that can come out of your stakeholder contesting everything.

The thing is, is whenever we deal with stakeholders in general and for this particular request, we use, or what I use, is a, no, but, mentality. It's the opposite of the improv yes, and, because I used to yes, and a lot, and that got me into a lot of trouble. So I use the opposite, I guess the no, but. So for this instance, if a stakeholder was coming to me, asking for a lot of really small changes and really small tests, what I would say is no, but we could do either an un-moderated usability test where we can get 25, 30, 40, 50 people. That's one option. No, but we can do an AB test. Much more statistically significant, much more impactful for those very, very small changes. Or alternatively, we can put together a lot of these small changes and stitch them together into a bigger project. So there you go.

If your stakeholder's coming to you with all these requests, and you're saying yes right now and doing all these random studies that aren't impactful, these are three ways to mitigate that stakeholder.

And I would also say the second scenario, the second main scenario that happens is that you get swamped. You just get so inundated with user research studies, and then you, honestly, want to pull your hair out, if you have hair, if you don't have hair, you want to scream. If you can't scream, you want to pound the walls. You want to do something to express your frustration and that makes you less impactful as a researcher.

So really mitigating these expectations. And one of the ways that I do this alongside the whole, no, but situations is education. So educating on when user research makes sense, when it doesn't make sense, give a very clear presentation to your stakeholders on this. If this is the problem that you're having, user research doesn't make sense, but some of these other things do. If this is your question, user research does make sense. This is when you come to me. So you can sneak in your timelines a little bit there to get them to come to you earlier. So in this scenario, it's a mixture of education and offering alternatives. So that is really the best way to deal with a stakeholder who is coming to you to try and test everything.

All right. So the second scenario that we're going to cover today is when your stakeholder doesn't think there's a need for user research. So it's the exact 180 of the stakeholder that wants to test everything. This stakeholder doesn't want to test a thing. They will often ask you things like, why do we have to do user research? What's the point of doing user research? Is there actually a need for doing research on this project? This happens all the time. I don't really understand why it happens all the time, because I feel like there's a lot of resources out there that's like do user research if you want your company to succeed. But hey, people have bad experiences, people don't understand things. Often it's due to misalignment, not anybody being mean or angry about something. So what I would say is at first, when I got this question, why do we need to do user research? Or do we need to even do user research for this project? Or I don't think we need to, which is the worst out of them because that's not a question it's a statement.

I used to beg and plead people. I used to be like, please we need to do this, it's so important, you got to understand why it's so important, please, please, please, we need. It's very convincing as you can see. So what happened is not only was that not a great tactic, but it really frustrated me because then I felt like my role was just running around and begging people to do something that nobody wanted to do. And so that made me feel extremely un-impactful and undervalued in an organization. So the next time that I got this question, I switched my mindset a little bit. And this is what I would really, really encourage you to do when you start getting these questions.

Go into user research mode, become a researcher, ask your stakeholders questions, ask them things like, why do you feel negatively about research? Or, what happened the last time you did user research? Or, what are the barriers, the biggest barriers to getting this research project done or to incorporating research into this project? Or, what are some ideal outcomes of this project if we do user research? So what this does is it allows us to understand the why behind what they're saying. So when they're saying, I don't think we need to user research, we're sitting there and understanding why they feel that way. Maybe they had a bad experience. Maybe there's a lot of pressure coming from somewhere else that we don't see and we need to understand that we might need to de-scope the research to fit into this timeline. Maybe they're scared that the product isn't going to get great feedback.

So these are all things that we can understand, we can empathize with as researchers, and then we can use them to help this person see where user research would be valuable. So if it's a time problem, if it's a money problem, we can then say, all right, if it's a time problem, let's de-scope this research, let's minimize it. Let's do un-moderated testing over the weekend instead of a full blown usability test. It goes back to that no, but. They're telling you no, and you're saying, but this time. And so you're understanding how to get around these roadblocks. If they've had a negative experience with research in the past, talk to them, understand what it is, empathize with them. It's the same thing where I've had in the past really bad experiences with the agile framework, but I can't say no to agile because that's what everybody does. But it makes me apprehensive because of fitting in research. But the thing is, is when people understand that, then they're better able to help me. And it's the same thing. So then you can help your stakeholder.

And as a bonus in this conversation, if you're able to understand what their goals are, so if their goals are something like increasing retention or increasing acquisition, it's often very metrics based, revenue based, business based, if you're able to understand their business goals and then stitch together, okay, not only have I come up with a project that's less time intensive, but it will help us understand this business metric, you suddenly have more buy-in. So really turning it around and shifting our mindset away from begging people to try and do research or trying to over and over again, be like, this is the general value of user research, that generic thing. Instead, let's understand why they're so hesitant about this, what their goals are, and then marry the two and create a project that really works for them.

So the final stakeholder scenario we are going to be covering today is when your stakeholder requests a answer to a business problem, rather than asking a research based question. So people ask what they know. Stakeholders know business. Oftentimes product managers will come to me and they will ask me a business related question and understanding it more deeply because they're embedded in the business. The business is such a crucial part of their role in impacting the business that they ask for what they need. But oftentimes these are not user-centric questions. They're not research questions. They are very leading. They are not at all in the scope of something that you could simply walk up to a user and ask them.

So a great example of this is when a product manager comes up to me and they're like, okay, not enough people are making accounts on our website, we need to make more people sign up. How do we do that? And I'm like, okay, I can't answer that, that's a business question, is getting more people to sign up. It's not a user research related question. So we need to fine tune this in order to turn it into a research question.

What I would love to do now is demonstrate why this doesn't really work as a research question. And I'm going to imagine that we brought this question of, how do we get more people to sign up or make accounts, into the real world? So into a user session. And Ben is going to be our participant today. So imagine that I just take this question about why people aren't making accounts or how to make them sign up more. And so I go to Ben and I say, hey, why aren't you making an account on our website?

Ben:

I don't know if I need one. I don't know if I need one or not.

Nikki:

Okay. Why don't you know?

Ben:

Why don't I know?

Nikki:

Yeah.

Ben:

I guess I'm just not sure. I'm not sure why I don't know.

Nikki:

Okay. So what would make you sign up for an account then?

Ben:

An account I don't know I need?

Nikki:

Yeah. Anything, really anything. What would make you sign up.

Ben:

Free things. I like free stuff or discounts.

Nikki:

Okay, great. That doesn't work. I did a few things in there and I will reference some of the videos that Ben and I have also worked on where I asked, what would make you sign up for an account, which is a future based question, which is unreliable completely. Not only that, but I interrupted Ben when he was like, ah, I don't know. And I was like, okay, shut up. Really anything, give me anything, because I'm clearly not getting an answer from you because you're very unsure because I'm asking you terrible questions. And then you said discounts. And so then I could go back and I could say, ah, okay, discounts would make people sign up.

So, unfortunately, Ben was unreliable and not giving us valid or truthful answers. This also has to do with social desirability bias, which we touched upon where it's pressured to give any sort of answer, even if it's not truthful. But this just does not give us any sort of data that we should be delivering our teams because this is misinformation. This could make us go in a completely wrong direction. And I've seen it actually happen like that, where the business question was asked in research and answers were given that were not truthful and then products and features were created that just completely failed. The team was demotivated, the participants were uncomfortable, and then ultimately the users were frustrated because we were doing all these other things, but we weren't solving their problems. That was really frustrating to them.

So instead, what we have to do is we have to turn these business questions into more user research related questions. So things that are problems for users or things that are pain points for users or the goals they're trying to achieve, or the unmet needs that they have. And so what we're doing there is we're asking them about things that they would actually want solved. So instead of saying, okay, accounts are really important, why aren't you opening account? We can say things like, okay, what's going on? What's a big pain point that you're having? And then we learn that it's not about accounts, it's about something completely different. And so again, we're getting more towards the user instead of the business. So this isn't always helpful or great for stakeholders, because they're like, I don't want to go around and circle around this, but there are a few things that you could do to help convert a business problem into more of a user research problem.

So the thing that I do is I ask myself some questions. So I ask first and foremost, and I sit with a stakeholder while I'm doing this, is this a customer problem? Normally the question is, no, it's not a customer problem or we can lie and we can say, yes, it's obviously a customer problem. And then you ask for data that it is, and then there's nothing there. So then it goes back to that first answer of no, it's not a customer problem. And so then we can ask other questions like, why would customers care about this? Or why should customers care about this? Or how would this help our customers or how would this impact our customers? Or have we heard this in previous research? And these are all questions that we can ask to get us closer to a more user centered problem that we're trying to solve. So if we take this business problem of, why aren't people making accounts? How do we get more people to sign up? So is this a customer problem? No, customers do not care about our revenue and our account engagement. Why could they care about this? Well, they probably don't care about this unless it's a painful experience.

So that starts to get a little bit more interesting. How would this impact our customers? Okay, well, we're not sure, so we're hypothesizing here. If we make the account experience better and people sign up, they might stay for longer and they might get information that's important to them. We might help them stay in the loop with something that they're interested in. So now we're starting to get to those hypothesized unmet needs, those hypothesized, pain points. And then we always ask, have we heard this in previous research? No, but we've heard something similar. Okay, so now we're starting to construct more of a user based problem. So what I would say is I would take this problem of, how do we get people to sign up for more accounts? And I would turn that into a goal of uncover the different pain points people encounter when signing up for an account. Or, additionally, if we wanted to look at people who already have an account, uncover the pain points with having an account, discover the unmet needs of our accounts. And so now we're pivoting this into a more user based question where we're trying to understand the user's problems, the user's perspective on this, rather than asking what would make you make an account? And so then ultimately we're still answering that question.

So that's the flow that I follow when a stakeholder comes to me with business account, question it, ask them about this type of question, and then convert it into something that is more user focused, but still answering that original question.