Spoke · Case study patterns

UX case study examples

What strong UX case studies do, what weak case studies miss, and how to tell the difference in 90 seconds. Annotated patterns covering hero summaries, decisions sections, outcome honesty, AI integration, and the reflection layer that separates competent case studies from convincing ones.

Jamie Pow13 min readSpoke · Portfolio cluster

The five sections of a UX case study

Strong case studies in 2026 share five structural sections. The structure isn't sacred — variants work — but the underlying logic is consistent: open with a hero summary that earns the next 90 seconds of attention, frame the context, name the decisions, report outcomes honestly, and reflect briefly on what could have been better. Case studies missing two or more of these sections rarely get full reads.

This article walks through each section with side-by-side strong and weak examples. The strong examples are composite — drawn from patterns that recur in case studies that convert. The weak examples are equally composite — drawn from patterns that recur in case studies that lose reader attention. Names and details are illustrative.

Hero summary — strong vs weak

Weak hero summary. "This project was a redesign of the X feature for a leading fintech company. I worked with a cross-functional team using design thinking methodologies to create a user-centred solution that delivered meaningful value to our users."

What's wrong: nothing is specific. No company named, no role named, no problem identified, no outcome stated. Five sentences of filler. A hiring manager reading this learns nothing and moves on.

Strong hero summary. "I led the redesign of Monzo's first-time-use flow for international transfers in Q3 2024. The previous flow had a 47% drop-off at identity verification; we needed to reduce friction without weakening compliance signals. The redesigned flow shipped to 100% of new users in November and reduced drop-off to 28% across the following quarter."

What works: company named, role specific ("led"), date specific, problem framed in one sentence with a number, outcome stated honestly with a comparable number. A hiring manager reading this knows immediately whether the case study is worth their next 8 minutes.

Context — strong vs weak

Weak context. "Users were facing challenges with the existing flow. We conducted research and discovered that there were many pain points across the journey. Our team aligned on the need to reimagine the experience."

What's wrong: no specifics, no tension named, no constraint articulated. The reader has no way to judge whether the problem was real or invented for the case study.

Strong context. "International transfers are Monzo's third-largest revenue stream and have the highest first-time-use abandonment in the product. The verification flow had been built in 2019 under regulatory advice that has since loosened. The PM's hypothesis was that we could reorder the verification steps to defer the highest-friction step until trust was established, without violating SARs guidance. Compliance disagreed initially. The product team had a two-sprint window to validate before quarterly planning."

What works: specific business context (third-largest revenue stream), specific constraints (regulatory, time-boxed), specific tension (compliance disagreed). The reader now understands what the project was really about and what the candidate had to navigate.

Decisions — strong vs weak

The decisions section is the most important. Hiring managers spend disproportionate time here, because this is where they assess whether the candidate can think under constraint.

Weak decisions section. "We created wireframes, then high-fidelity designs. We iterated based on feedback from stakeholders. The final design used a clean, modern aesthetic with clear hierarchy."

What's wrong: no decisions named. The reader sees activity, not judgement. There's no alternative to compare against, no trade-off to assess.

Strong decisions section. "Three significant decisions shaped the redesign:

  1. Move identity verification to step three (after the user has committed to a recipient and amount) rather than step one. Trade-off accepted: a small group of users who would abandon at step three regardless would now invest more time before abandoning. We modelled this as a 2% net negative against the projected gain.
  2. Show verification time estimate upfront ("3 minutes") rather than hiding it. Hypothesis: transparency reduced abandonment more than the implied time commitment increased it. We tested this in a usability round with 8 users; 7 preferred the transparent version.
  3. Defer document upload to a separate session via email link rather than forcing it in-flow. Trade-off accepted: longer time-to-first-transfer for users without ID ready; lower friction for users who could complete the rest of the flow. Compliance signed off after we confirmed audit trail integrity.

What works: three explicit decisions, each with alternative considered, evidence informing the call, and trade-off accepted. The reader can now evaluate the candidate's judgement — and can probe specific decisions in the interview if they want to.

Outcomes — strong vs weak

Weak outcomes. "Increased engagement by 320%. Improved user satisfaction. Delivered significant business impact. The team and stakeholders were thrilled."

What's wrong: inflated, unanchored numbers; no methodology stated; no acknowledgement of attribution. Senior reviewers spot this pattern instantly because the numbers don't match the design changes.

Strong outcomes. "Drop-off at verification reduced from 47% to 28% across November and December. Net new transfer signups +14% quarter-on-quarter, against a baseline trend of +6%. Two confounders worth naming: a separate marketing campaign launched in November and may account for ~3pp of the lift; compliance approval for in-app document upload arrived in December and may account for a further ~2pp. Net of these, the verification reorder is responsible for ~14pp of the 19pp drop-off reduction, which the team treated as the project win."

What works: specific numbers with comparable baselines; methodology and confounders named honestly; a clear statement of what the candidate is and isn't claiming as project impact. This level of honesty signals senior judgement and consistently outperforms inflated metrics.

Reflection — strong vs weak

Weak reflection. "This was a great learning experience. I'm proud of what the team delivered. I look forward to applying these lessons in future projects."

What's wrong: generic. Could be from any case study. Communicates no judgement.

Strong reflection. "The thing I'd revisit: I spent too long modelling the projected net negative on the deferred-verification decision before bringing compliance into the conversation. We could have shortened the cycle by a week if I'd taken the early draft to compliance review rather than waiting for stronger evidence. The pattern I want to break: optimising for being right rather than for being fast enough to be useful."

What works: specific, honest, names a pattern the candidate is working to change. Reflection at this level builds significant credibility, often more than the project outcome itself.

AI in case studies

2026 case studies are increasingly expected to address AI use honestly. Two patterns recur in strong AI integration:

AI as a workflow accelerator. "I used Claude for synthesis across 24 user interviews; manual cross-validation on a 20% sample confirmed the synthesis held. This compressed synthesis from 3 days to 4 hours and freed time for additional usability rounds." Specific, honest, evaluative.

AI as a design constraint. "Because the recipient search uses an LLM, latency and confidence varied. We designed the input pattern around a 'searching, then suggesting' UX state to absorb uncertainty without breaking trust." Treating AI as a real design constraint rather than a generic feature.

What weakens AI in case studies: speculative "I redesigned [large tech company]'s AI feature" projects with no shipped reality. Hiring managers have seen too many to credit them. The broader cluster view is in AI for UX designers; the what AI should not replace in UX piece covers the boundary articulation.

90-second diagnostic

Ask three questions of any case study. If you can't answer all three from the first screen, the case study needs work.

  1. Whose problem was this and what was getting in the way?
  2. What did the candidate decide, and what trade-off did they accept?
  3. What happened?

Most case studies fail the diagnostic on question two. The fix is structural: add a decisions section to every case study with two or three specific decisions, alternatives considered, and trade-offs accepted. This single change resolves the majority of case study failures we see.

For the full reference on portfolio structure, see portfolio examples and the portfolio guide. The reusable structure is in the case study template (downloadable PDF and DOCX). The diagnostic patterns to avoid are in portfolio mistakes. For interview defence of these case studies, see interview preparation guide.

If you want help writing or restructuring case studies, independent UX-experienced writers on Fiverr offer case study writing and restructuring support, typically £50 to £200 depending on depth.

Frequently asked questions

What should a UX case study contain?

Five sections: hero summary, context, decisions, honest outcomes, reflection. Each has a job. Case studies missing two or more usually don't get full reads.

How long should a UX case study be?

Five to eight minutes of reading time. Roughly 1,200 to 1,800 words plus screens.

Can I write a UX case study about a project that didn't ship?

Yes, and senior hiring managers often value these case studies more than 'wins'. The framing matters: name the situation honestly, describe what you did and didn't control, reflect on what you'd do differently.

Continue in the cluster