Most design case studies are written for the wrong person.
I see this constantly — designers who write for other designers, who list every method they touched (competitor analysis, user interviews, affinity mapping, card sorting) as though the label proves something. Your case study isn't a methods section. It's a story with a point, aimed at someone specific, doing a specific job.
Here's what I've learned about writing one that actually works.
Know who you're writing for before you start
The same project should be written differently depending on where it lives.
On your portfolio — recruiters and hiring managers are evaluating your skill as a designer. They want to see your process and the decisions you made. Focus on how you approached the problem, what choices you made, and what you shipped. They're selling you to someone else; give them the story that makes that easy.
On Medium — other designers come here to learn. Focus on insights: what did you discover that others don't already know? What would change how someone else thinks about a similar problem? The question isn't "what did I do?" — it's "what can readers take away?"
On Dribbble or Behance — visual platforms are for scrollers. Show your most interesting UI moments. This is not the place for long text or process documentation.
On LinkedIn — your professional network cares about business impact. Frame the work in outcomes: what changed because of this design? Not "I redesigned the dashboard" but "the redesign reduced support tickets by 30%."
Writing one version and posting it everywhere is the most common mistake. A process-heavy portfolio piece on LinkedIn bores people. A visual-only post on your portfolio gives recruiters nothing to evaluate.
Start by setting up context
Before your reader cares about your solution, they need to understand the situation. Answer these before you show any screens:
- What's the product, and who uses it?
- What specific problem were you solving?
- What were the constraints — timeline, team, technical, business?
- What was your role on this project?
Write for someone encountering your project for the first time. Don't assume they know your company or domain. Every sentence should be readable without background knowledge.
Focus on insights, not steps
The most common failure in design case studies is listing steps instead of sharing what you learned.
"I conducted user interviews. I synthesized insights. I created wireframes. I tested prototypes."
Nobody needs to read that. Everyone does those things. What matters is what you discovered and how it changed your direction.
Did your research reveal something surprising? Did a user test invalidate your first design? Did a constraint force a more creative solution than you would have found otherwise? That's the actual story. Lead with the insight.
A useful test: could you tweet any sentence from your case study and have it feel worth reading? If not, that sentence probably isn't adding much.
Talk about what didn't work
This is the hardest thing to include and the thing that makes case studies genuinely interesting.
The design that went through three pivots is more instructive than the one that shipped first try. Show the version you thought would work, what you learned, and how you adjusted. Recruiters aren't looking for perfect designers. They're looking for designers who can navigate uncertainty and improve.
"We thought the problem was X. Research showed it was actually Y. Here's how that changed the design" is a far more compelling story than a linear happy path.
Design the reading experience
People don't read case studies — they scan them. Design accordingly.
Use headings that tell the story even if someone reads nothing else. Short paragraphs. Visuals instead of description wherever possible. Put your most interesting images large, not small.
After writing your first draft: cut 20%. Then cut 20% more. The constraint forces you to keep only what's actually worth keeping. Most first drafts contain a lot of process justification that the reader never needed.
Obsess over visuals
Your case study visuals are part of your portfolio. If your screens look rough, recreate them. This is your chance to make the work look as good as it can. One strong, well-crafted frame tells more than five mediocre ones.
Show prototypes and motion, not just static screens. A working flow gives reviewers something to experience rather than just evaluate. Use large images — small thumbnails make your craft hard to see.
Only show work you're proud of. A case study with three strong screens is better than one with twelve average ones.
Make it yours
The case studies I remember are the ones where I could feel the designer cared about the problem.
Why did this project matter to you? What part of the process gave you energy? What opinion did you form about the design problem that you hadn't had before? That voice — specific, opinionated, personal — is what makes a case study memorable. Recruiters review hundreds of them. The ones with a clear point of view stand out.
Before you publish, run through this checklist (originally curated by Ansh Mehra, expanded here):
- Simple language and short sentences throughout
- More execution shown than process
- A GIF or Loom video for key interactions
- Figma prototype embedded at the end
- If someone scans only the headings, they still understand what the project is about
- A non-designer friend has read it and understood it
Write for the right person. Cut what doesn't serve them. Show your actual thinking — not a cleaned-up version of your thinking, but the real reasoning, including the pivots.
Credits & further reading
- Ansh Mehra — the non-negotiable checklist at the end of this note is his. He's built one of the most practical libraries of UX career advice I've found. Follow him if you're actively job searching as a designer.
- The "align the story with the medium" framing — the idea that the same project needs different framing depending on whether it lives on your portfolio, Medium, Dribbble, or LinkedIn — came from design community best practices I collected across multiple sources including Uxfolio's writing guides and various design career educators.
- Articulating Design Decisions — Tom Greever (O'Reilly). The section on how to present to executives versus engineers versus developers directly maps to how you should write case studies for different audiences.
- 10k Designers case study library — 10kdesigners.com/case-studies. Real case studies from designers who've been through the same curriculum. Useful benchmarks for what strong work looks like.