UX case study before and after

Why most case studies fail

Most weak UX case studies share a common origin: they were written to demonstrate process rather than communicate thinking. The author was taught that documenting methodology was the way to demonstrate UX rigour, so the case study became a chronological narration of activities — research workshop, persona, journey map, wireframes, high-fidelity, ship.

This structure produces case studies that hiring managers cannot evaluate. The reader can see what activities happened; they cannot see what the candidate decided, what they considered and didn't choose, or what trade-offs they accepted. The thinking — the senior signal — is invisible.

The before-and-after pattern in this article shows the specific edits that move a case study from process narration to decision evidence. The examples are composite, drawn from patterns that recur in case studies the UX Companion review process has worked with.

The pillar reference is UX portfolio examples. The strong vs weak diagnostic deep-dive is in case study examples. The reusable structure is in the case study template.

Hero summary — before and after

The hero summary is the single most diagnostic section. A weak hero summary loses the next 8 minutes of reader attention; a strong one earns them.

Before. "This case study explores my work on a redesign for a major fintech client. Working with a cross-functional team, I applied design thinking to create a meaningful user experience that delivered value to our customers and met the business objectives."

After. "I led the redesign of Monzo's international transfer onboarding for the team responsible for the product's third-largest revenue stream. The previous flow had 47% drop-off at identity verification; we shipped a reordered flow in November 2024 that reduced drop-off to 28% across the following quarter."

What changed. Three editorial moves. Company named instead of "major fintech client". Role specified ("led" instead of "working with"). Problem and outcome both given specific numbers with timeframe. The reader now knows whether the case study is worth their time within 15 seconds.

Problem framing — before and after

Before. "Users were experiencing pain points throughout the existing journey. We conducted research and identified opportunities to improve the user experience. The team aligned on a need to redesign the flow."

After. "International transfers were the team's third-largest revenue stream and had the product's highest first-time-use abandonment. The existing flow had been built in 2019 under regulatory advice that had since loosened. The PM hypothesised that reordering verification steps could reduce drop-off without weakening compliance signals. Compliance disagreed initially. We had two sprints to validate before quarterly planning closed."

What changed. The before is generic — could be any project, anywhere. The after is specific: business context, historical constraint, named hypothesis, named tension, named time-box. The reader can now evaluate the project against real constraints rather than abstract pain points.

Decisions — before and after

The decisions section is the heart of the case study. Most weak case studies skip it entirely; many treat it as a list of activities rather than a list of choices.

Before. "We created wireframes based on the research insights. Through iteration with stakeholders, we refined the designs to reach the final solution. The high-fidelity designs used a clean, modern aesthetic with clear visual hierarchy."

After. "Three significant decisions shaped the redesign.

(1) We moved identity verification to step three rather than step one. Trade-off: a small cohort of users who would abandon at verification regardless would now invest more time before abandoning. We modelled this as a 2pp net negative against the projected lift, which the team accepted.

(2) We surfaced verification time estimate ('3 minutes') upfront rather than hiding it. Hypothesis: transparency would reduce abandonment more than the implied time commitment increased it. We tested with 8 users in usability rounds; 7 preferred the transparent version. Hypothesis confirmed in the cohort small enough that I flagged the limit to the PM.

(3) We deferred document upload to a separate session via emailed link. Trade-off: 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 with the security team."

What changed. Three explicit decisions with alternatives considered, evidence informing the call, and trade-offs accepted. The reader can now evaluate the candidate's judgement and can probe specific decisions in the interview if they want to.

Outcomes — before and after

The outcomes section is where credibility lives or dies. Inflated metrics damage credibility instantly; honest outcomes build trust over time.

Before. "Increased user engagement by 320%. Improved customer satisfaction. Delivered significant business impact. The team and stakeholders were thrilled with the result."

After. "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 changed. Specific numbers with comparable baselines. Methodology and confounders named honestly. Clear statement of what the candidate is and isn't claiming as project impact. The honesty signals senior judgement and consistently outperforms inflated metrics at hiring committee review.

Reflection — before and after

Reflection is the section most weak case studies skip and most strong case studies use to build the strongest single signal of judgement.

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

After. "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 validation 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 is optimising for being right rather than for being fast enough to be useful."

What changed. 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.

Storytelling shifts

Beyond the section-level edits, three storytelling shifts move case studies from weak to strong.

From chronology to causality. Weak case studies are organised by what happened in what order; strong case studies are organised by what mattered and why. The reorganisation often means cutting workshops and synthesis sessions that didn't lead to a named decision.

From "we" to "I". Weak case studies use "we" throughout, leaving the reader unable to evaluate the candidate's specific contribution. Strong case studies use "I" specifically for the candidate's choices and "the team" or named collaborators for cross-functional work. The discipline is unfamiliar at first but becomes natural after a rewrite.

From process to product. Weak case studies dedicate disproportionate space to methodology (Double Diamond, design thinking, persona artefacts); strong case studies dedicate space to the design output and the thinking behind it. The methodology is implied, not narrated.

Structural rewrites

Some case studies need more than section edits — they need full structural rewrites. The diagnostic for "rewrite vs edit": if the case study has decision content but in the wrong structure, edit. If the case study doesn't have decision content at all, rewrite from scratch using the case study template.

The rewrite from scratch process: name the project, write the hero summary first, then the problem framing, then the two or three significant decisions you actually made, then the honest outcomes, then a specific reflection. The output should fit on 6–10 pages of writing plus screens, totalling 5–8 minutes of reading time. This output usually beats the polished original.

If you want help with the rewrite — particularly for senior case studies where the writing carries disproportionate weight — independent UX writers on Fiverr offer case study writing and restructuring support. Useful when the candidate has strong projects but struggles with the writing layer.

The rewrite process

A working sequence for rewriting a weak case study in a weekend.

Saturday morning (2 hours). Read the existing case study against the diagnostic in case study examples. Mark every section that doesn't earn its place. List the two or three significant decisions you actually made on the project (write them out fresh, not from the existing case study).

Saturday afternoon (3 hours). Rewrite hero summary, problem framing, and decisions section from scratch using the case study template as scaffold.

Sunday morning (2 hours). Rewrite outcomes and reflection. Pay particular attention to honesty about attribution and confounders.

Sunday afternoon (2 hours). Cut the methodology slides, persona slides, journey maps that don't earn their place. Update visuals to support the new structure.

The full review pass after the rewrite is in portfolio review checklist. The completeness pass is in portfolio checklist. The broader career view is in how to get your first UX job for early-career and how to become a UX designer in 2026 for the industry view. The salary context is in UX designer salary UK. For the interview round that follows, see interview preparation guide and salary negotiation guide.

Frequently asked questions