March 3, 2021
March 3, 2021
There are times when I get super excited about solving business problems for an organization. After speaking with a data analyst or looking into Google Analytics, I find a spot in our product that isn't performing well. For instance, there's a considerable drop-off rate during our check-out flow or a high bounce rate on the homepage, or people sit on a particular page for a long time (what are they looking for?!?).
Utilizing user research to understand why these things may be happening helps us connect our value as researchers to the business. I can go straight to a product manager and say, "Hey, we're having these issues in our analytics; let's look into this with research." Likely figuring out those metrics is a shared goal with the product manager, leading to easier buy-in.
Instead of always talking to users to find out more problems to tackle, it is also interesting to start from the other way around. Look at Google Analytics or data you have collected to see where they might be in the product.
As I have mentioned before, whenever a research request comes my way, I always have the requester fill out an intake document. In this, I ask them what the business problem is and, separately, what the customer problem is. Frequently, the business problem is copied and pasted into the customer problem. Trust me, I've tried varying the order to ask about the customer problem first, but the same result ensues.
What's wrong with this? I just mentioned how great an opportunity to start a project from a business perspective, so what is the problem?
A business problem is NOT necessarily a user problem. However, a user problem is almost always a business problem.
So, when a research request comes in saying, "Not enough people are signing up" or "People aren't using our product across their teams like they are supposed to" or "Users are dropping off during our funnel," I have to say:
"So what? That isn't a user problem."
I am in no way saying that figuring out why these business problems are happening isn't essential. Approaching user research from the business side can be an excellent way to start a project; however, we have to be very careful as researchers. In an ideal world, it would go like this:
Researcher: "Why are you just sitting on this page for so long and doing nothing?"
Participant: "Oh, well, I look at your website, and I compare it to many other websites, so I am going through a lot of tabs."
Researcher: "Interesting. What do you want on our website then?"
Participant: "If you could tell me the price compared to all these other websites and prove it is one of the lowest, I wouldn't look on other websites, and I'd just buy right away."
Researcher: "Great! We will get to work on that!"
The problem is, that's not how research works. We can highlight business problems, but we can't ask our users to fix them. Users and customers don't care about our metrics or business problems; they care about whether or not the product works for them. If we aren't asking the right questions to users about their issues (not the ones we are), we aren't helping them. And, if we aren't helping them, those metrics won't change.
If we start by understanding what the user/customer cares about, we will solve the correct issues rather than business metrics. And, most likely, if we solve user/customer problems, the metrics will become more favorable and improve.
However, since many colleagues we work with come from the business perspective, it is not always easy for them to automatically convert a business problem into a potential user problem. As user researchers, we have to help them translate business needs and issues into user problems to focus on finding out the most critical information and doing the most impactful research study.
Whenever I see a potential business problem in analytics or through speaking with colleagues, I automatically figure out a potential user problem in my head. Keep in mind, by coming up with a user problem, we don't delete the business problem. That is why I ask those two separate questions: business problem and user problem. After we brainstorm and test solutions, the business problems and metrics should indicate if we chose the best solution.
Generally, whenever I get a research request with a business problem highlighted as a user problem, I work together with my colleagues to pull apart a user problem. I could easily do this on my own, but this is a great time to educate your stakeholders on the differences and help them cultivate a user-centric mindset.
To understand the potential customer problem behind the business issue, I ask the following questions:
After this exercise, we brainstorm some user problems that are associated with the original business problem. This part is a fun way to include and educate your colleagues even further. If they understand the differences, they may approach you next time with a business problem and a user problem!
Let's say a product manager approached you with a joint business and user problem in an intake document.
Business/user problem: Not enough people are signing up for our subscription. We see a decline in subscription revenue by 5%.
Now going through the steps, you would ask:
If the subscription revenue is declining, you might have a problem with people canceling their subscriptions. However, I would focus on one question at a time.
Overall, it is fantastic to walk the line between business and the user as a user researcher. With these skills, you can speak to both colleagues and the user and solve the most critical problems for both.
Nikki Anderson-Stanier is the founder of User Research Academy and a qualitative researcher with 9 years in the field. She loves solving human problems and petting all the dogs.
To get even more UXR nuggets, check out her user research membership, follow her on LinkedIn, or subscribe to her Substack.