Question 1
Difficulty: easy
How do you decide which research method to use for a product question?
Sample answer
I start by clarifying the decision the team needs to make, because the method should serve the decision, not the other way around. If we need to understand why users are struggling, I’ll lean toward interviews, diary studies, or contextual inquiry. If the team needs to size an issue or compare options, I’ll use surveys, usability testing with task success measures, or analytics review. I also consider timing, sample access, and risk. For example, if we are early in discovery and have no clear hypothesis, I prefer qualitative methods first to uncover patterns and language. If we are validating a specific design, I’ll combine moderated usability testing with a lightweight survey or product data. I like to explain tradeoffs clearly so stakeholders understand what the method can and cannot answer. That usually keeps the research focused and avoids overengineering the study.
Question 2
Difficulty: medium
Tell me about a time you had to influence a product decision using research.
Sample answer
In one project, the product team wanted to simplify onboarding by removing several setup steps they assumed were unnecessary. I was concerned we were optimizing for speed at the expense of user confidence, so I proposed a quick usability study with new customers and a small review of support tickets. The sessions showed that two of the “extra” steps actually helped users understand how the product worked and reduced anxiety about making mistakes. Instead of just saying no, I reframed the insight around risk: the issue was not length, it was clarity. I worked with design to shorten the copy, add progressive disclosure, and keep the reassuring steps while removing one redundant field. The team shipped the updated flow, and completion rates improved without increasing support requests. What worked well was grounding the recommendation in evidence and presenting alternatives, not just problems.
Question 3
Difficulty: medium
How do you recruit participants for a UX research study?
Sample answer
I recruit based on the research objective, not just convenience. First I define the behaviors, experience level, and context that matter most. If we are studying a common workflow, I may need a mix of novice and experienced users. If the product serves multiple segments, I make sure the sample reflects the right segment for the question. I usually collaborate with product, customer success, or marketing to source participants, but I’m careful to screen for the actual criteria I need. My screeners are short, specific, and built to avoid leading questions. I also look for bias risks, such as recruiting only highly engaged users when the goal is to understand friction. For qualitative studies, I aim for enough diversity to surface patterns without trying to be statistically representative. I keep a recruiting tracker so the team can see who participated and where the sample might be skewed. That transparency helps everyone trust the findings.
Question 4
Difficulty: medium
What do you do when stakeholders disagree with your research findings?
Sample answer
I expect disagreement sometimes, especially when findings challenge a roadmap decision. My first step is to listen and understand where the concern comes from. Often stakeholders are not rejecting the research itself; they are worried about sample size, method, or whether the findings apply to their audience. I address that directly by walking through the study design, showing clips or notes, and connecting the evidence back to the original question. If needed, I’ll suggest follow-up research or triangulate with analytics, support data, or another method to build confidence. I also avoid being defensive, because the goal is a better product decision, not “winning” an argument. One thing I’ve learned is that stakeholders respond well when I translate insights into implications and options. If they still choose a different path, I document the tradeoff clearly so we can measure the outcome and learn from it later.
Question 5
Difficulty: easy
Describe how you would run a usability test for a new feature.
Sample answer
I would begin by defining the core tasks the feature is meant to support and the decisions the team wants to make afterward. Then I’d create a short test plan with realistic scenarios, success criteria, and probes for key moments of confusion. I prefer tasks that reflect actual user goals rather than telling participants exactly what to click. During the sessions, I stay neutral, encourage think-aloud, and avoid rescuing participants too quickly so I can see where the experience breaks down. I usually look for patterns across participants rather than isolated comments, and I note both behavioral and emotional cues, because frustration often signals a design issue even when the task is technically completed. After the sessions, I synthesize findings into severity, impact, and recommended changes so the team can act quickly. If possible, I’ll include a short highlight reel because seeing real behavior makes the insights much more actionable than a slide deck alone.
Question 6
Difficulty: medium
How do you balance qualitative and quantitative research in your work?
Sample answer
I see qualitative and quantitative research as complementary, not competing. Quantitative data helps me understand the scale of a problem, where it occurs, and whether it is changing over time. Qualitative research helps me understand why it is happening and what users are trying to achieve. In practice, I often start with product analytics or survey data to identify a pattern, then use interviews or usability testing to explain it. Other times I do it in the opposite order: a few exploratory interviews reveal a theme, and then I use a survey or log analysis to see how widespread it is. The balance depends on the question, the stakes, and the timeline. I’m careful not to force one type of data to answer everything. When I present findings, I like to connect the numbers to the human story, because that helps teams understand both the size and the meaning of the problem.
Question 7
Difficulty: hard
Tell me about a time you had to work with limited time or resources.
Sample answer
I once had only one week to help a team choose between two homepage concepts before a design freeze. A full research study was not realistic, so I focused on getting the highest-value input with the least overhead. I narrowed the objective to the main decision: which concept communicated value more clearly and created less confusion. Then I ran five moderated usability sessions with target users and used a simple comparison framework so I could review findings quickly. I also pulled in a few existing analytics metrics and customer support trends to see whether the concepts aligned with known pain points. The result was not a perfect, exhaustive study, but it was enough to show that one concept buried the most important message. The team adjusted the layout and copy before launch. I learned that good research under pressure is about discipline: keep the question tight, use the right method, and avoid collecting more than you can analyze well.
Question 8
Difficulty: easy
How do you turn research findings into actionable recommendations for product teams?
Sample answer
I try to make recommendations specific, prioritized, and tied to user impact. A finding alone is interesting, but teams usually need to know what to do next and why it matters. I start by identifying the root cause behind the behavior, then I translate that into a design or product implication. For example, instead of saying “users were confused,” I might say “users could not predict what would happen after clicking this button, so add clearer labels and inline feedback.” I also separate must-fix issues from nice-to-have improvements, especially when teams have limited bandwidth. When possible, I connect each recommendation to evidence from sessions, quotes, or metrics so it feels credible and not just opinionated. I like to partner with designers while framing recommendations because they often have better ideas for execution than I do. My goal is to leave the team with clear next steps, not just a list of observations.
Question 9
Difficulty: medium
How do you handle a situation where research participants behave differently from your own expectations?
Sample answer
That situation is actually one of the most valuable parts of research, because it reminds me not to confuse assumptions with evidence. When participant behavior surprises me, I first check whether there was an issue with the study setup, such as confusing tasks, biased wording, or a sample mismatch. If the methodology looks solid, I treat the unexpected behavior as a signal worth exploring, not something to explain away. I’ll look for patterns across participants and compare them with other data sources like analytics, support tickets, or prior research. Sometimes the discrepancy reveals that users have adopted a workaround we did not know about, or that the product is serving a different mental model than the team expected. I try to bring that back to the team in a constructive way: our assumptions were wrong, but now we have a better understanding of the real behavior. That usually leads to stronger design decisions.
Question 10
Difficulty: hard
What metrics or signals do you use to evaluate whether UX research has had an impact?
Sample answer
I look at both direct and indirect signals. Directly, I want to see whether the research changed a decision, clarified a direction, or reduced uncertainty for the team. That could mean a design issue got fixed, a feature scope changed, or a hypothesis was abandoned before it cost time and effort. Indirectly, I look at whether the team uses the research in planning, whether stakeholders return with better questions, and whether insights are referenced in roadmap discussions. On the user side, I may track task success, conversion, error rates, retention, or support volume, depending on the problem. I’m careful not to claim causation too quickly, because many factors affect product metrics. Still, I think research should create visible movement, not just reports. One of the best indicators for me is when teams start asking for research earlier in the process, because that means they’ve seen the value of having user evidence before decisions are locked in.
