Hiring managers read case studies the way editors read manuscripts: quickly, sceptically, and looking for a reason to stop. A case study’s job is to survive that reading — and the ones that do are almost never the prettiest. They’re the clearest about judgement: what you knew, what you decided, and what happened because of it.
This is the structure I use for my own case studies and recommend to designers I mentor. It’s a template in the loose sense — a default order you should deviate from whenever the project demands it.
Start from what the reader needs
Three audiences read case studies, and they want different things:
- The screener (2 minutes, maybe less) wants to know: real project? sensible process? can this person write?
- The hiring manager (10 minutes) wants evidence of judgement: trade-offs, constraints, collaboration, and honesty about results.
- The interviewer (returns before your call) wants hooks — specific decisions they can ask you to defend.
The structure below serves all three by being ruthlessly front-loaded: everything a screener needs sits above the first scroll, and depth unfolds for anyone who keeps going.
The structure
1. Executive summary
Four or five sentences: the product, the problem, your role, the approach, the outcome. Write it last, place it first. If a reader stopped here, they should still have an accurate — just compressed — picture of the project.
2. Context, problem, and constraints
Readers can’t judge your decisions without knowing what you were up against. State the business situation, the user problem, and the constraints (time, tech, politics) plainly. Constraints are not excuses — they’re the reason your judgement was necessary.
A design decision that looks wrong without context often looks smart with it. Context is how you get credit for the hard parts.
3. Your role, exactly
“I owned the interaction design and research; a senior designer owned visual direction” builds more trust than “I led the design” ever will. Precision about your role is a credibility signal in itself — vagueness here is the single most common reason experienced reviewers discount an otherwise good case study.
4. Research — sized to the risk
Show what you did to replace assumptions with evidence, and be honest about scale. Five interviews are five interviews; don’t dress them up as a study. One well-chosen research verbatim does more work than a paragraph of summary:
Include the user’s words when they changed what you built — not as decoration, but as the moment the team’s understanding shifted.
5. The decisions section — your centrepiece
This is the part most case studies are missing, and the part interviewers care about most. For each significant decision, cover three beats:
- The alternatives you seriously considered
- The trade-off you accepted and why
- What you’d revisit knowing what you know now
Two or three decisions covered honestly beat ten covered superficially.
6. The work itself
Flows, wireframes, and final screens — captioned. A figure without a caption is decoration; a caption that explains what to notice turns it into evidence. Show unglamorous states (empty, error, loading) deliberately: they signal production experience faster than any hero shot.
7. Results, with honesty
Verified numbers, with their source and timeframe. And when you don’t have numbers — which is often, and normal — say what you do have: qualitative signals, stakeholder outcomes, or simply “the feature shipped and I left before results matured.” A candid “we didn’t measure this well” is more impressive to experienced readers than a suspicious “+40%” with no source.
8. Lessons and next steps
One or two real lessons (not “communication is important”) and what you’d do next. This section is short, but it’s where you demonstrate that you metabolise experience — the trait that predicts how you’ll grow on their team.
What to leave out
- Process theatre — a double-diamond diagram tells the reader nothing about your thinking
- Tool lists as achievements — tools belong in metadata, not the narrative
- Every screen you drew — curate; the reader trusts you more when you clearly chose
- Unverifiable claims — one fake-smelling metric poisons every real one
A checklist before you publish
- Can a screener understand the project from the summary alone?
- Is your role stated precisely enough that a teammate could confirm it?
- Does at least one section show an alternative you rejected, and why?
- Does every image have a caption that says what to notice?
- Is every number sourced — or honestly absent?
- Did you read it aloud once? (It catches more than any grammar tool.)
The structure won’t make a weak project strong. But it will stop a strong project from reading like a weak one — which is the more common tragedy.
Writing or reworking your own case studies? I occasionally share breakdowns like this — subscribe on the writing page or see how I apply this structure in my own case studies. And if your team needs this kind of thinking applied to a real product, get in touch.