Most UX portfolios fail not because the work is bad but because the case studies don't show the work clearly. Over-focused on UI. Under-written on thinking. Silent on commercial outcomes. This template fixes that, directly.
Available templates
The structure on this page is the canonical version. Downloadable file versions in PDF, Notion and Figma are rolling out; sign up to the newsletter and the links land in your inbox as they ship.
The 9-block case study template
The full structure, ready to paste into Notion, Google Docs, Read.cv, or wherever your portfolio lives.
The decision block
The micro-structure that turns "process narrative" into "evidence of thinking". Use it inside any case study.
Portfolio-ready Figma file
Drop-in Figma case study template with the nine blocks pre-laid out, sized to common portfolio platforms.
The portfolio reviewer checklist
A 25-point checklist of what hiring managers actually check before opening a case study. Use as a self-review before publishing.
Why most case studies fail
Three failure modes explain almost every weak case study I review.
- Too much UI, not enough thinking. The case study reads as a screenshot reel. The reviewer sees what shipped but not why those choices were made.
- Process worship over decision evidence. Long sections about the Double Diamond. Generic methodology language. No actual decisions named.
- Outcomes hidden or inflated. Either no metrics at all, or numbers so optimistic they read as fabricated. Either pattern breaks credibility.
The structure below solves all three. It forces the writer to foreground thinking, name decisions, and be honest about outcomes.
The nine-block structure
One block per section. Every case study uses the same nine blocks. The depth of each block scales with the complexity of the project, not the writer's enthusiasm.
The nine blocks
01 — HERO SUMMARY [Project title] One paragraph (3-4 sentences): company, role, problem in one line, outcome in one line. One hero image: the strongest single screen, not a montage. 02 — CONTEXT What was the business trying to do? What was getting in the way? Name the tension at the centre of the project. 03 — YOUR ROLE What did you own end-to-end? What did you contribute to? Who else was in the room (engineering, PM, research)? 04 — RESEARCH Lead with the insight, not the method. "Six interviews surfaced one finding I hadn't expected..." Mention the method in passing. If there was no formal research, say so. 05 — PROBLEM FRAMING One sentence (sometimes two). The sharpened question this case study answers. "How might we [specific] without [trade-off]?" 06 — PROCESS AND DECISIONS Two or three real decisions you wrestled with. Each follows the decision micro-template below. 07 — SOLUTION The final design, annotated. Three to six key screens, each with rationale (not description). 08 — OUTCOME Numbers if you have them. Plain qualitative evidence if you don't. Be honest about scope and certainty. 09 — REFLECTION One paragraph. What you'd do differently. What the project taught you that you carry forward.
The order matters because it tracks how a reviewer actually reads. Top-down summarises; middle proves; bottom reveals self-awareness.
The hero summary
The single most important block. A reviewer decides whether to keep reading inside the first 30 seconds. The hero summary has to do almost all the work.
Good: "I led the redesign of the mobile checkout for a UK retailer doing roughly £1.2bn online. Cart abandonment was running at 78%. After two rounds of testing and a phased rollout we brought it to 62% in twelve weeks."
The second version answers four questions before the first version has answered one. That's the bar.
The decision micro-template
The decision block is the heart of every case study. It's where the writer demonstrates that real choices were made under real constraints. Use the micro-template below for each decision.
How to write one decision
THE QUESTION The choice that had to be made. "Should the saved-card state surface by default or only on the cart screen?" THE OPTIONS The two or three real options considered. Not "we explored many options"; the actual two or three. THE TRADE-OFFS What each option cost. Engineering effort, user friction, design system consistency, business risk. THE DECISION What you chose and why, in plain language. What you accepted as the trade-off cost. THE EVIDENCE (OPTIONAL) Screenshot, test result, analytics number, or quote that supports the decision.
Three real decisions written in this format will outperform twenty paragraphs of process narrative. Every single time. This is the template that fixes "too much UI, not enough thinking".
Evidence and outcomes
The outcome block is where credibility lives or dies. Two rules.
Numbers when you have them
State the metric, the change, the timeframe, and the confidence level. "Cart abandonment dropped from 78% to 62% over twelve weeks, measured against the previous quarter's baseline." Specific, attributable, falsifiable.
Honest qualitative when you don't
If the project didn't ship or you don't have analytics access, say so directly and substitute qualitative evidence: stakeholder feedback, user quotes, what the team did with the work after you left. A short, honest acknowledgement is far more credible than a vague claim of impact.
What never works: inflated metrics, ambiguous percentages without baselines, "users loved the new design" without evidence. Reviewers smell this in seconds.
Length and presentation
The right length is whatever clears the brief without filler. The practical target.
- Five to eight minutes of reading time.
- 1,200 to 1,800 words of prose, plus screens.
- Four to six high-quality screens, each earning its space.
- Body text at 16-18px with 1.5 to 1.75 line height. Max width around 65 characters per line.
Anything shorter usually skips the thinking. Anything longer rarely gets read end-to-end by a reviewer working through twenty portfolios.
NDA and confidential work
The most common question I get from designers in big companies. The short answer: you can almost always write about a project without exposing the things that are actually confidential.
What's usually protected: unreleased UI, internal data, strategy decks, supplier contracts, specific revenue numbers, named partners. What's almost never protected: how you thought about the problem, the methods you used, the trade-offs you considered, what you learned.
Three practical moves that work.
- Genericise the product. "A mobile checkout for a UK retailer doing roughly £1bn online" is more credible than a redacted brand name.
- Blur, reconstruct, or stylise the UI. A clean wireframe of the final screen often communicates better than a redacted screenshot anyway.
- Use ranges instead of exact numbers. "Cart abandonment dropped from the high seventies to the low sixties" is usually fine where "78% to 62%" might not be.
If at all unsure, email your former manager. In a decade of hiring, I have never seen a sensible employer object to a thoughtful, redacted case study about work the designer genuinely did.
Common case study mistakes
Six patterns that explain most weak case studies. Avoid these and you're already in the top quartile.
- Process worship. Long sections about frameworks (Double Diamond, design thinking). Scaffolding, not content.
- Methods montage. Grid of every research method you've used. Looks thorough; signals nothing about your judgement.
- Vague pronouns. "We did this." Hiring managers want to know what you specifically owned.
- No problem, no decisions. Case study walks from brief to final mockup with no visible choices.
- Aesthetics over substance. Beautiful portfolio chrome wrapped around a case study that says almost nothing. Hiring managers see it and assume the designer cares more about looking good than thinking.
- Identical case study templates. All three case studies follow the same template down to the heading order. Bootcamp signal.
Frequently asked questions
How long should a UX case study be?
Five to eight minutes of reading time. 1,200 to 1,800 words plus screens. Anything shorter usually skips the thinking; anything longer rarely gets finished.
What sections should a UX case study include?
Nine: hero summary, context, your role, research, problem framing, process and decisions, solution, outcome, reflection. The decisions section is the heart and where reviewers spend the most time.
Can I write a case study about NDA work?
Yes, with care. Describe process, decisions and learnings without exposing protected screens, numbers, or strategy. Genericise the product, blur the UI, use ranges for metrics.
What if the project didn't ship?
Be honest. The trade-offs and the reflection are often the strongest parts. A killed or descoped project is still useful evidence of how you think, provided you can articulate what you'd do differently.
First person or third person?
First person ('I') for what you personally did. Plural ('we') for collective team decisions. Avoid the passive voice; it hides the designer, which is exactly the opposite of what the reviewer wants to assess.