Skip to main content

UX Research and User Interviews

You're running user interviews for a product decision β€” a new feature, a redesign, a pivot hypothesis. You have a discussion guide, you've recruited participants, and you're about to spend 45 minutes with each of them. The risk: most user interviews generate interesting conversations and then produce either confirmation of what the team already believed, or a set of user requests that point in different directions and produce no clear signal.

Bad research isn't usually caused by bad questions. It's caused by wrong frameworks β€” asking about preferences when you should be asking about behavior, interpreting answers literally when you should be listening for the underlying need, or drawing conclusions from what users say when the real data is what users do.

The Framework β€” Step by Step​

Step 1: Use Jobs to Be Done to Frame What You're Actually Trying to Learn​

Why this model fits: Jobs to Be Done (developed by Clayton Christensen) reframes the research question from "what do users want?" to "what job are users trying to get done, and what alternatives are they currently using to get it done?" This distinction produces fundamentally more useful research.

How to apply it:

  1. Before writing your discussion guide, define the job hypothesis: What functional, social, and emotional job are we investigating? For example, for a project management tool: the functional job is "coordinate a team toward a deadline." The social job is "demonstrate to stakeholders that things are under control." The emotional job is "reduce the anxiety of being responsible for something complex."
  2. Design your questions around job execution, not product preferences. Not "what features would you like to see?" but "walk me through the last time you had to coordinate a project across three or more people β€” what were you doing, what went wrong, and what did you use to manage it?"
  3. Focus on past behavior, not future intentions. "Would you use a feature that does X?" is almost useless. "What did you actually do the last time you faced X?" is gold.
  4. Listen for "switch moments": when did users hire a new solution (or a workaround) to do the job? What was the trigger? What were they trying to get away from?

The key question: What job is this user trying to get done β€” and what does the way they currently do it tell us about where the pain actually is?

Step 2: Use Empathy Mapping to Capture What Users Say, Think, Do, and Feel​

Why this model fits: Users in interviews often say one thing while doing another, feel differently than they report, and think things they don't say out loud. An Empathy Map structures your observations across all four dimensions β€” preventing you from treating reported preferences as complete data.

How to apply it:

  1. During or immediately after each interview, map what the user: said (direct quotes), did (behaviors described or demonstrated), thought (implied beliefs and mental models, even if not stated), and felt (emotional states observed or inferred).
  2. Pay particular attention to the gaps. When a user says "I love this product" but describes workarounds they use daily, the gap between "said" and "did" is the insight. When a user describes a painful workflow calmly, but their word choice reveals frustration, the gap between "said" and "felt" is the insight.
  3. After 5–6 interviews, aggregate your empathy maps. Look for patterns across participants: which feelings are common? Which behaviors are consistent? Which stated preferences are contradicted by described behaviors?
  4. The highest-value insights are almost always in the gaps β€” not what users said they want, but what their actual behavior reveals they need.

The key question: Where do this user's words and actions diverge β€” and what does that gap tell us that the words alone wouldn't?

Step 3: Apply the Ladder of Inference to Validate Your Interpretations​

Why this model fits: After collecting data, researchers draw conclusions. The Ladder of Inference shows how conclusions are built from interpretations built from filtered observations β€” and how researchers can skip steps without noticing. Applied to UX research, it prevents you from presenting conclusions to the product team that are actually three levels of inference away from the raw data.

How to apply it:

  1. For each key insight you plan to present, trace back down the Ladder: This is my conclusion. What interpretation led to it? What specific observations supported that interpretation? Did I filter those observations from a larger set β€” and why those and not others?
  2. Present insights with their evidence chain explicit. "Three of five users had a workaround for X [observation]. All three said they didn't trust the system's default behavior [interpretation]. Our conclusion: there's a trust deficit in the core workflow [conclusion]." This allows the product team to engage with the evidence, not just the conclusion.
  3. Identify where your conclusions are strong (grounded in multiple consistent observations) versus tentative (based on one or two data points).
  4. Explicitly flag alternative interpretations for each key insight. "An alternative interpretation of the same behavior is Y. Here's why we think X is more likely, but Y should be explored."

The key question: At which step in my reasoning did I move from observation to interpretation β€” and did I mark that transition clearly?

Full Workflow​

UX Research β€” Framework

Step 1: Jobs to Be Done Framing ──  Output: Research questions anchored in job execution
          ↓
Step 2: Empathy Mapping  ─────────  Output: Multi-dimensional behavioral profiles per user
          ↓
Step 3: Ladder of Inference Audit ─  Output: Evidence-grounded insights with alternatives

Common Mistakes​

Asking about preferences instead of behavior. "Would you use this feature?" predicts almost nothing. "Tell me about the last time you needed to do X" predicts a great deal.

Presenting conclusions without evidence chains. Research reports that say "users want X" without showing which users said or did what cannot be evaluated or challenged by the product team. This reduces research to advocacy.

Recruiting participants who are too similar. Homogeneous samples produce homogeneous insights. Deliberately include edge cases, non-users, and churned users β€” the most important signals often come from outside the typical user profile.

Apply This Framework with AI​

Describe your research context and the product decision you're trying to inform in MindMax. The AI will help you design JTBD-grounded interview questions, build an empathy map structure, and validate your interpretations.

πŸš€ Design your research in MindMax β†’

This page is part of the MindMax Mental Models Knowledge Base.