How to Write a UX Case Study

What is a UX Case Study?

A UX case study tells the story of a design project from problem through solution to impact. It’s not a portfolio piece showing pretty mockups. It’s a narrative explaining your thinking, decisions, and results.

A case study answers: What was the problem? Why did it matter? How did you solve it? What did you learn? A strong case study shows your process, not just your output.

One sentence punch: A case study transforms “here’s what I designed” into “here’s how I thought, and here are the results.”**

Why Case Studies Matter

• Shows Your Process — Employers want to see how you think, not just what you produce. Process reveals thinking.
• Demonstrates Impact — A case study that ends with “5% conversion improvement” is stronger than one ending with “I designed this.”
• Tells a Story — Stories stick. Data disappears. A narrative about solving a problem sticks with hiring managers.
• Differentiates You — Anyone can show designs. Few show thinking. Case studies separate junior designers from senior ones.

Case Study Structure

1. Introduction (1 paragraph) — What was the project? Why does it matter?
2. Problem (2-3 paragraphs) — What was broken? What did users struggle with? Why was it worth solving?
3. Research (2-3 paragraphs) — How did you understand the problem? What did you learn from users?
4. Solution (3-4 paragraphs) — What did you design? Why did you make those choices? Show key screens/mockups.
5. Results (1-2 paragraphs) — What was the impact? Numbers are powerful (conversion, retention, engagement).
6. Learnings (1 paragraph) — What would you do differently? What did you learn?

Writing Tips

• Show your thinking, not just your output. “I designed a button” is boring. “I tested three button colors and found blue had 15% higher click rate, so I chose blue” is interesting.
• Use data where possible. “Users said navigation was confusing” is okay. “80% of users took 4 clicks to find the feature; after redesign, 1 click” is powerful.
• Include process visuals. Show wireframes, sketches, user journey maps. The journey is interesting, not just the destination.
• Be honest about constraints. “We redesigned within the existing codebase, which prevented X” is credible. Never claim impossible feats.
• Show iterations. “First attempt was rejected because of Y. Second attempt addressed Z. Final solution combined the best of both.”

Common Mistakes

• Too much focus on final design — Case studies that are 90% mockups and 10% process are weak. Reverse the ratio.
• Missing numbers — “Improved engagement” is vague. “Improved engagement by 23%” is concrete.
• No failure or learning — Case studies that claim everything worked perfectly are unbelievable. Show challenges.
• Unclear problem statement — If the reader doesn’t understand why the problem matters, they won’t care about the solution.
• Incomplete research explanation — How many users did you interview? What did you ask? Show your work.

Mentor Tips

• First tip: Case studies are 30% outcome, 70% process. The best case study isn’t the biggest project. It’s the one with the clearest thinking.
• Make it scannable. Not everyone reads word-for-word. Subheadings, bolded key points, and visuals let skimmers understand the key narrative.
• Tell the story chronologically. Walk the reader through your thinking as it happened. Suspense and discovery feel more real.
• Proofread obsessively. Typos in a case study scream carelessness. Your writing is part of your design.

Resources and Tools

• Books: “Resonate” by Nancy Duarte (storytelling), “Show Your Work” by Austin Kleon
• Tools: Figma for presentations, Medium or personal blog for publishing
• Articles: Case study guides on Nielsen Norman, portfolio tips on UX Collective