“We don’t need user research…”
The ability to convince stakeholders they need user research seems to be a more important job requirement than the actual ability to conduct research sessions.
I once had someone approach me and say, “you know what, user research is overrated.” This person knew I was a user researcher. I no longer talk to this person (not because of what they said in that instance, but their general attitude towards life).
Even though user research is becoming more mainstream and popular, dare I say it’s “trending,” there are still many challenges faced when thinking about implementing a user research practice into a company. The most common is getting buy-in from (usually) higher-level stakeholders. The ability to convince stakeholders they need user research seems to be a more important job requirement than the actual ability to conduct research sessions.
I have worked at companies where user research wasn’t particularly valued — some to the point where I seriously considered why they hired me in the first place. It was difficult to consistently have to be fighting for research, fighting for what I did (or was meant to be doing) on a day-to-day basis. When someone comes up to you and tells you how unimportant user research is, it can be infuriating and really defeating.
Usually, what I have found, are there are common misconceptions about user research and the value it brings. Typically, people shy away from the amount of time user research can take. What they may not understand is user research can fit properly into sprints. It doesn’t have to take months! My favorite (and simultaneously least favorite) argument, however, is:
“We already know what our users want and need”
Now, this statement is tough. I can understand people’s rational fears of time, money, added value, and I can speak to those when I explain to them my plan for user research.What becomes more difficult, without research, is telling a higher-level executive they have no idea who their customers are and that they are wrong. For example:
Boss: “I think we should implement this new feature that makes customers rate our products they just bought before being able to browse new products.”
UR: “Why do you want that?”
Boss: “Because we can get more ratings on our product and make it more obvious how to rate.”
UR: “But how would that make for a better experience for our customers?”
Boss: “I’ve worked here for quite some time, I know what our users want. I think they’ll love it.”
UR: “ But how do you know they will love it? Based on my previous research projects, I’m not sure if they would. Maybe we should test this?”
Boss: “We don’t need to test it, that would be a waste of time. I know it’s a good idea, so that’s what we will do.”
This may be an extreme example (or maybe not), and I have definitely heard it before. You could argue the time issue here, but I doubt that is actually a concern. The most concerning part of this is the implementation of a feature without the thought of research (generative or evaluative), based on the fact that someone who has been working at the company, or in the industry, for some time just knows. When you have the opportunity to so research, it is best to choose that path rather than making the gut decisions.
So, here we are, talking about how we are going to implement a horrible new feature that will, most likely, dissatisfy or annoy our customers. As a user researcher, this is tough and we have all been here. I will ask two questions: why is this happening? What can we do to solve this?
Why is this happening?
This boss is a person who is trying to make the best decisions based on the information they have in front of them — which is their experience and understanding of the customer, regardless of how right/wrong that is. The answer may seem illogical, but this response of “I know what is best” is a fall back tactic when you don’t have the time to explain your rationale. This rationale might be something you are familiar with or it might be something completely outside your mind, such as “the CEO said this” or “I need to hit X numbers by a certain date” or “I saw data that said this was a good idea.” Just because they are thinking this, doesn’t mean they will explicitly state their reasoning. In addition, the boss is probably interacting with many people during the day, who are saying what decisions should be made and giving their own opinions on situations. Out of all those people, you are only one voice.
What can you do?
Most of the time, I would like to prove the boss wrong and to show them actual user research that disproves their hypothesis. I want to push the research. I want customers to be happy. What if, instead, we try methods that give the boss more tangible solutions rather than “we need to research that.”
Boss: “Implement this rating feature!”
UR: “What an interesting idea. I’d love to run it through our research process, where we test next features to make sure users value them, and they work with our current product. We do this to make sure customer satisfaction, acquisition and growth metrics stay high. By testing any changes before implementing them, we are able to know that we are iterating towards success, keeping business KPIs up, and not just making changes because someone has a feeling”
Or
UR: “That would be a great addition to the test we are running this week. I’ll make sure to send you the results as soon as we have them in about two weeks, so you can use them for further conversations.”
Or
UR: “Have we done previous research on the benefits of that feature?”
Boss: “No”
UR: “Let’s put a prototype together in the next few days. We can go out and guerrilla test it with our users — I would love it if you could join us.”
Or
UR: “Let me talk to the team and come up with some potential benefits of that feature, including how and when users would use it. Can I get that to you by the end of next week?”
Bottom line, offer a solution with a tangible artifact at the end, so the boss has something they can reference or use. Although it may sit in their back pocket, there is a much higher chance they will be more open to the discussion in the future if you give them something. Eventually it could turn into a more consistent and user-focused process.
Bosses are only as much of an antagonist as you make them. Tell them about the different actions you can immediately take to give them something real, and they may just take your side.
An aside
In one way, I will agree, there are certain times where user research doesn’t fit in, but I will tweak the saying a bit: you don’t need half-assed user research. This may be controversial. A lot of people may say, “any research is better than no research.” Sure, in theory, that is correct. When you need something, any of that thing is better than none of that thing. The difference, however, is that research can be done wrong. And it can go wrong fairly easily with those who may not have the proper understanding or training. Doing half-assed, improper research can actual hurt the company and prohibit them from finding a researcher, or someone knowledgable in user research to help them down the road. A now and a future problem.