What a case study is for
A UX case study shows how you think, not how you decorate. Hiring managers read it to judge your judgment.
A case study is the written story of one project: the problem you faced, the decisions you made, and what happened as a result. It is not a gallery of your prettiest screens. Screens only prove you can operate design software. A case study exists to prove you can reason your way from a fuzzy problem to a defensible solution.
Think about what the reader actually needs. A hiring manager cannot watch you work, so your case study is a substitute for sitting next to you during a project. They want to know how you handle ambiguity, how you respond to evidence, and whether you can explain a decision without hiding behind jargon. Every section you write should answer one of those questions.
-
keywords
- #CaseStudy
- #Judgment
- #Storytelling
The structure that works
You do not need a clever format. You need a clear one. Four parts, in order, cover almost every project.
Context and the problem
Start with who the product serves, what was going wrong, and the constraints you worked within. Two or three paragraphs are enough. A reader who does not understand the problem cannot appreciate the solution, so earn their attention here before showing anything visual. Be specific: "checkout abandonment on a grocery delivery app" tells a story that "improving the user experience" never will.
Your role
If the project was a team effort, say exactly what was yours. "I led the usability testing and designed the payment flow; a senior designer owned the visual system" reads as confident, not weak. Reviewers have worked on teams too. They can smell inflated credit, and honesty about your slice of the work builds trust in everything else you claim.
Process
This is the longest section, and it should read like a series of decisions, not a parade of methods. Instead of listing every activity you performed, explain the two or three forks in the road: what options you considered, what evidence tipped you one way, and what you abandoned. Include the dead ends. A direction you tried and dropped, and the reason you dropped it, is exactly the kind of thinking a reader came for.
Outcome
End with what shipped, what moved, and what you would do differently. If you have a real result, state it plainly. If the project never launched or you have no numbers, say so and describe the qualitative signal you did have, such as testing results or stakeholder adoption. A reflective closing about what you would change next time signals more maturity than any polished metric.
-
keywords
- #Context
- #Role
- #Process
- #Outcome
Process over pixels
The messy middle of a project is the interesting part. Final mockups all look competent; decisions look like you.
New designers tend to hide their rough work and lead with the shiniest artifact. Resist that. The wireframe you abandoned says more about your thinking than the final mockup ever will, because it shows you generated options, tested an assumption, and changed course when the evidence disagreed with you.
Show the sketch next to the revision and write one honest sentence between them: what you believed, what you learned, and why the second version is different. That single before-and-after beats ten annotated screens of the finished product.
-
keywords
- #MessyMiddle
- #Iteration
- #Decisions
Honest constraints beat fake perfection
Real projects have tight deadlines, no research budget, legacy code, and stakeholders who push back. Pretending yours did not makes your story less believable, not more impressive. Naming a constraint and showing how you adapted to it is one of the strongest moves a case study can make.
Could not recruit participants? Explain how you ran hallway tests with five colleagues and what you did to limit the bias. Had two weeks instead of two months? Show what you cut and why that was the right thing to cut. A stakeholder overruled your recommendation? Describe what you negotiated to protect and what you conceded. These moments are where judgment becomes visible, and judgment is what the reader is hiring.
-
keywords
- #Constraints
- #Tradeoffs
- #Adaptability
Common mistakes
Most weak case studies fail in the same few ways. Check yours against this list before you publish.
The framework parade. Ten diagrams proving you know ten methods, with no thread explaining why any of them mattered to this project. Methods are tools, not trophies.
Walls of text. If a section cannot be skimmed in seconds, it will not be read. Short paragraphs, clear sub-heads, and one idea per block.
No outcome. A story that ends at the mockup feels unfinished. Even "we shipped it, and here is what I would test next" is an ending.
Claiming solo credit. Saying "I" for work a team did. It unravels the moment an interviewer asks a follow-up question.
Leaking confidential details. If you signed a non-disclosure agreement, anonymize the client, blur sensitive data, and never publish unreleased work. Violating an NDA in public is a louder signal than anything else on the page.
-
keywords
- #FrameworkParade
- #Readability
- #Credit
- #NDA
Tailoring the depth
Different readers spend different amounts of time on your work. A recruiter may skim for thirty seconds; a design manager preparing your interview may read every word. Write in layers so both readers get what they need: bold summary lines for the skimmer, full reasoning underneath for the reader who stays.
A short overview at the top, covering the problem, your role, and the outcome in three sentences, serves the skimmer completely. The sections below reward the careful reader. Neither audience should have to dig for what they came for.
-
keywords
- #Recruiters
- #Skimming
- #Layers
Takeaways
One case study done well beats five rushed ones.
Depth is the differentiator. Pick the project where you made real decisions under real constraints, tell that story honestly with context, role, process, and outcome, and cut the rest. A reader who finishes one strong story will assume you can repeat it. A reader who skims five shallow ones will assume you cannot go deeper.