Presenting a UX Research Case Study: The Four Questions Your Case Has to Answer

There is a specific way research presentations fail, and it has nothing to do with the research.

The candidate presents a study: here was the question, here was the method, here were the participants, here is what we found. It's rigorous, it's honest, it's well-organised — and at the end the panel has learned what the researcher did without learning whether it mattered. Someone asks "so what happened?" and the answer is "it went into the backlog."

The panel is not evaluating your study design. They're evaluating whether research done by you changes what a team does. Everything below is built around making that unmissable.

The four questions

Not a slide structure — a checklist. If your case answers these four in this order, the structure takes care of itself.

Question 1 is the one to fix first. A case that opens with "we wanted to understand how users experience onboarding" has no stakes. A case that opens with "engineering was three weeks from rebuilding the onboarding flow and nobody could agree on what was wrong with it" has a clock running, and the panel leans in.

A worked case

Here is one, presented the way it would actually be delivered — about seven minutes spoken, which is the right length for a twenty-minute slot with questions.

The decision waiting. "The team had committed to rebuilding onboarding in the next quarter. Completion was 41%, and there were two theories in the building. Design thought the flow was too long — seven steps. Growth thought the problem was upstream, that we were attracting people who were never going to activate. Those imply completely different rebuilds, and the team was about a week from picking one by seniority."

That's the opening. Sixty seconds, and the panel now knows what the research was for and what it would have cost to get it wrong.

The method, and its cost. "I had two weeks and no budget for recruitment, so a longitudinal diary study was out even though it would have been the better instrument. I ran eight moderated sessions with people who had signed up in the previous fortnight and not completed — recruited from our own list, which I'll come back to because it's the weakness — plus a funnel analysis of the seven steps to tell me where to point the sessions.

The funnel first, deliberately: it's cheap and it tells you where to spend the expensive qualitative time. Without it I'd have spent eight sessions asking people to narrate all seven steps and learned very little about any of them."

Naming what the method cost you — the diary study you couldn't run — is what makes the choice read as a decision rather than a default.

The numbers.

"Two steps carry two-thirds of the loss, and neither is 'the flow is too long'. So the design theory, as stated, doesn't survive contact with the funnel — though something adjacent to it does."

What nobody expected. "The email verification drop isn't a design problem and it isn't an intent problem. Six of the eight sessions stalled at the same place, and the reason was the same each time: the verification email arrived while they were still on the signup screen, on a different device. They'd finished signing up on a laptop and the email was on their phone. Four of the six never went back to the laptop tab at all — they assumed they were done.

So we weren't losing people who didn't want to activate. We were losing people who thought they already had."

What changed. "Three things. We made the verification step non-blocking — you can reach the end of setup unverified and verify later, which took the step out of the funnel entirely. We changed the email copy from a welcome to a single instruction. And we stopped the rebuild: the team had been about to redesign seven screens, and the finding turned that into a two-week change to one.

Completion went from 41% to 58% over the following six weeks. I'd attribute most but not all of that to the verification change — we also had a copy change in step 4 in the same window, and I can't cleanly separate them."

That last sentence is worth more than the 17-point improvement. It is the single most reliable signal of a researcher who won't oversell, and panels are listening for it.

The slide that decides it

Somewhere in your case, put what you got wrong.

Not a weakness in the method — an actual belief you held that the data killed. In the case above it's this: "I went in expecting the drop to be at team invite, because that's the step with the social cost and it's where I'd have stalled. I pointed the first two sessions at it and wasted them. The funnel was telling me step 2 from the start and I didn't believe it, because 23% felt too big for an email."

Two things happen when you say this. The panel stops wondering whether you're presenting a sanitised version, which they were. And you've demonstrated the thing the job is: changing your mind when evidence arrives, on the record, in front of people.

The sample-size question

Someone will ask it. Usually phrased as "eight participants — how confident are you that's representative?", and it is not a hostile question. It's a test of whether you understand what your own method can and cannot support.

The answer that fails is defensive: "eight is standard for qualitative research, you reach saturation around five." True, and it dodges what they asked.

The answer that works separates the two claims your study makes:

"Eight can't tell you how many people hit this — that's what the funnel is for, and the funnel is the whole population. What eight gets you is the mechanism: why the 23% happens. Six of eight hitting the same wall for the same reason is strong evidence about the mechanism and no evidence at all about prevalence. If someone needs a prevalence number I'd need a survey, and I'd want the sessions first anyway, because I wouldn't have known what to ask."

You've now shown you know which part of your finding is load-bearing. That's the actual question.

The wider set of things UX research panels probe — how you handle a stakeholder who doesn't want the answer, how you pick between methods under time pressure — is covered here: UX Researcher Interview Questions. If your round is a portfolio review across several projects rather than one deep case, the shape is different and it's covered in the design portfolio presentation walkthrough.

Preparing yours

Pick the study where something changed. Not your most rigorous one — the one with a consequence attached. If your best-designed study went into a backlog and your scrappiest one stopped a rebuild, present the scrappy one and be honest about its limits.

Then write the four answers as four sentences before you open any slide software. If sentence four is vague, no amount of slide design will fix it, and you should pick a different study.