When you take a problem to a doctor or a mechanic, you don’t know the cause or how to resolve it. You’re trusting a specialist to figure it out and tell you what to do.

It’s the same with UX researchers. We’re specialists within our organizations. When product owners, designers or engineers approach us with problems, we listen. We ask questions. And we create a plan to help them achieve their goals.

Often, our first job is to diagnose and prescribe. In this article, I’ll share the four questions I ask to establish what the stakeholder’s fundamental problem is and how to best address it.

1. What’s your goal with this project?

When our stakeholders visit us, their goal is to get useful information to inform some decision or reach some outcome.

Our goal when visiting a doctor or mechanic is often to return to normal health or operation. Likewise, our stakeholders may want to fix a problem. For example, they may know from analytics that a certain function isn’t getting use, but they can’t figure out why.

Sometimes, we invest in preventative care, like an annual physical or a tune-up. Before our stakeholders invest their own resources, they may want to identify problems they’ve missed. Or even with a good understanding of what to do, they want a prioritized plan. There are always new frontiers for making technology better, too. They may want to explore those opportunities.

2. What kinds of people are we trying to reach?

As user experience researchers, finding users to speak with is a big part of our job, a big pain point, and a big expense.

So establish from the outset what profile or audience you will need to focus on for the project. Start thinking about how you’ll find people who match the profile. You will likely need to write a screener, and you may need a specialized recruiting service.

There may be a tension between the ideal audience and what’s most practical. An ordinary adult, or general population consumer, will be much easier to reach than, say, a senior IT professional with authority to set corporate policies or make purchasing decisions. As you identify the constraints of this project, it may make more sense to consider the easier profile.

3. What will we ask them about or show them?

Your stakeholders might want to understand the current process, or they may have a prototype of some feature they’re waiting to build.

Use this answer to start defining your method. If your stakeholders are still in an early discovery stage with their product, they may be best served by speaking with potential users about how they get similar outcomes today. Where are there problems that your team could address? If they’re close to shipping a feature, they may just need a usability test.

Return to the goals as well. Are they trying to get precision in their estimates or are they just looking for directional feedback? Use these clues to propose how many participants you’ll need and how you’ll reach them. For example, if the emphasis is on statistical certainty, you might consider a survey or unmoderated usability test.

4. When do you need to know the answer?

There’s an old saying: cheap, fast, and good — pick any two.

If you have an unlimited amount of time to complete a project, you might be able to do it both cheaply and well. In most cases, there is a deadline at which time the results are needed. And that deadline is often tighter than we’d like.

I’ll sometimes ask, “When’s the latest these results will be useful?” Finding out the “drop dead” date will help you to further refine the method. It may not make sense to define new personas — often a massive months-long project in several phases — if the deadline is next week. But you could run a quick survey.

Conclusion

Just like doctors and mechanics, UX researchers need to translate vague problems into a plan for action. You can do this with four questions:

1. What’s the goal with this project? Listen for which stage of development the product is in. Are they trying to identify problems and opportunities, or to assess and prioritize?
2. What kinds of people should we seek out? Define the ideal participant profile, and consider how you might find folks matching it. Start to think about less than perfect matches that still achieve the goal.
3. What will we ask them about or show them? Begin to define the approach. If there‘s a live site or prototype, you may want to do a usability test. If it’s too early on, methods like interviews may be better suited.
4. When do you need to know the answer? Tease out the deadline. You may need to scale back the approach to fit. Combine with answers to the other questions to arrive at your final method.

Your stakeholders don’t need to know anything about research. Their answers here will help you establish the method, participants, tasks, and timeline. Then, like any good doctor or mechanic, you can get to work fixing the problem.