How to write a UX case study (with a template)
A UX case study is not a highlight reel of screens - it's the evidence that you make good decisions. Get the structure right and it does the work of getting you interviews. This is the structure, a fill-in template, and the mistakes that get case studies skipped. For assembling several into a portfolio, see the UX portfolio guide.
The structure that works
Whatever you call it, strong case studies share one shape - context, action, result, evaluation:
Context - the problem and who had it
Open with the user problem and the stakes, framed as the job to be done - not "the client was a SaaS company". What was broken, for whom, and why did it matter?
Action - what you did, and what you ruled out
The research (affinity mapping, journey mapping, usability testing), the options you weighed, and the ones you rejected and why. The road not taken is what proves you decided rather than followed orders.
Result - what changed, measured
Tie it to an outcome: conversion, task success, error rate, a north-star metric - or, with no numbers, the evidence from testing. Never end without a "so what".
Evaluation - what you learned
One honest paragraph on what you'd do differently. It reads as seniority, not weakness.
Write it so a skimmer gets it
Reviewers spend under a minute on the first pass. Put a one-line summary and the outcome at the very top, before the long version. Lead each section with the decision, then the detail. If someone reads only the first screen of your case study, they should still know the problem, what you did, and that it worked.
The mistakes that get case studies skipped
Keep going, free
Every method above is a hands-on demo in the free interactive glossary. Get one UX term a week, explained by example: