How to Write a UX Case Study (With Real Examples)
Learning how to write a ux case study is less about formatting and more about proving one thing: that you can think clearly through messy work and explain it. Most case studies are not rejected for weak visuals. They are rejected because the reasoning behind the screens is unclear.
This guide walks through the structure section by section, with short snippets pulled from real example case studies so you can see the difference between a weak line and a strong one. Each example links to a full teardown if you want the complete version.
The one idea behind everything here: a hiring reviewer is not grading your Figma skills. They are deciding whether they would trust you with a real product problem. Every section below exists to answer that question.
Before you start writing
Before any section, answer three questions. If you can’t, the case study will read as vague no matter how good the UI looks.
- Who is this for? A junior role, a mid-level role, a product company, an agency? This shapes what you emphasize.
- What was your role? “Worked with the team” is not a role. Be specific.
- What problem does this case prove you can solve? Not what screens you designed — what kind of thinking you can be trusted with.
If you’re building your first piece and don’t have a client project, read how to write a UX case study with no experience before going further.
1. Context: set the scene in one paragraph
Context is not a story. It is the product, the users, the problem, and the constraints, in a few sentences. Keep it short.
Weak version:
“I designed an app to help people manage their money better.”
Strong version:
“Pilo is a consumer neobank. I redesigned the Send Money flow over six weeks, scoped to UI and flow only, with one PM and two engineers.”
Notice the constraints are already there: six weeks, UI only, small team. Constraints make a project believable. See the full fintech transfer teardown for how this opens a case.
2. Problem statement: make it specific and human
A strong problem statement is tied to a real user or business pain, written in plain language. The most common mistake is a problem so broad it can’t be designed against.
Weak version:
“Redesign the app to improve UX.”
Strong version:
“Users were dropping off at the transfer confirmation step, and support kept getting ‘I sent money to the wrong person’ tickets. In banking, one scary moment kills confidence — so this was a trust problem, not just friction.”
The strong version gives the rest of the case a target. A reviewer immediately understands what success would look like.
3. Your role and responsibilities
Reviewers scan this section first to assess your level. State what you owned, what you collaborated on, and — importantly — what you did not do.
Weak version:
“We conducted research and designed the solution.”
Strong version:
“I led product design on the Freightline operations dashboard, working with a PM, three engineers, and a data analyst. I owned research, the exception-first layout, and the severity system; the data analyst built the metrics feeding the dashboard.”
Naming what others did makes your own contribution more credible, not less. The B2B logistics dashboard teardown shows this in a large-team context.
4. Research and insights: show what you learned, not what you did
List methods only if you also show what they revealed. Raw activity is not insight.
Ask yourself: can someone understand what you learned in ten seconds? Avoid dumping survey questions, sticky-note photos, and obvious findings.
Weak version:
“I conducted user interviews, created an affinity map, and made personas.”
Strong version:
“Eight interviews with new pet owners surfaced one feeling over and over: overwhelm. The knowledge to do it right existed — scattered across Google, breeder PDFs, and forums — but nothing guided them through it calmly.”
The strong version interprets the research. It earns the design decisions that follow. The 0-to-1 pet-care teardown is built on exactly this kind of synthesis.
5. Decision-making: the most important section
This is where you prove how you think. For each key decision, show the decision, the alternatives you considered, and why you chose one over the others. This section matters more than how well you use Figma.
Weak version:
“I simplified the dashboard layout.”
Strong version:
“The core decision wasn’t a screen — it was a system: one shared language for risk (OK / At-risk / Breach) applied consistently across the whole product, so status means the same thing everywhere. I considered just fixing the status styling on this one screen, but it was shown five inconsistent ways across the product, so a local fix wouldn’t have solved the real problem.”
A second example, from a consumer redesign:
“I rebuilt the product page around one hierarchy — see it, choose it, trust it, buy it — because research showed conversion was a confidence problem, not a button-color problem.”
When the alternatives and the reasoning are visible, a reviewer can evaluate your judgment. The e-commerce PDP teardown shows a full decision chain.
6. Design execution: only what’s relevant
Show the path from wireframe to final flow, but only the parts that carry the reasoning. Every screen needs context. If the UI looks good but the why is missing, the case feels shallow.
Weak version:
“Here are the final screens.”
Strong version:
“The PDF schedule became an interactive, filterable schedule — pick a day and a track, and the sessions you care about surface instantly. I’m showing the before and after here because the change is the whole point: the old format was the funnel blocker.”
Pair each screen with the decision it represents. The event website teardown maps each screen to a funnel problem.
7. Outcomes and impact: be honest about evidence
Show what changed after launch, with metrics if you have them and qualitative feedback if you don’t. It’s fine if results are limited — explain what you would measure next. What is not fine is inventing impact.
If you have real numbers (clearly yours), use them:
“Task completion rose from 68% to 91% and wrong-send tickets dropped about 40%, while time-to-send stayed flat.”
If you have a concept with no production data, say so:
“This is a concept, so there are no production metrics. I validated direction with a prototype test on six new owners: comprehension was clear and self-rated confidence rose. I’m careful not to claim numbers it doesn’t have.”
If you ran a limited pilot, scope the claim:
“I piloted with one ops team for four weeks. Time to identify an at-risk shipment dropped meaningfully — I frame it as a pilot signal, one team and four weeks alongside other changes, not a platform-wide result.”
A reviewer trusts honest, scoped results far more than confident exaggeration. This is the single fastest way to look senior. We cover the failure modes in why UX case studies get rejected.
8. Reflection: show maturity, not perfection
End with what worked, what didn’t, and what you’d do differently. A specific reflection builds more trust than a flawless story.
Weak version:
“I learned the importance of user research.”
Strong version:
“I’d recruit users closer to the target audience next time. Two participants had more financial experience than the intended beginner user, so their feedback may have made the flow seem easier than it was.”
Common mistakes that read as red flags
Reviewers move on quickly when they see:
- a case that’s too long, with no clear hierarchy
- screens shown without explanation
- generic UX jargon in place of real reasoning
- no clarity on what you personally owned
- something that looks like a design exercise, not a real problem
- more attention on visuals than on thinking
If a recruiter has to work to understand your case study, they will move on.
The recruiter’s final scan
Before you publish, read your case the way a reviewer will and ask:
- Can I understand the problem in under 30 seconds?
- Is your role crystal clear?
- Do I see how you think, not just what you made?
- Would I trust you with a real product problem?
If most answers are yes, your case study is doing its job. For a printable version of this, use the UX case study checklist. To study full examples across project types — fintech, e-commerce, events, 0-to-1, and B2B — browse the UX case study examples.