A UX case study is an argument: given this problem and these constraints, here is what I did and why it was the right call. Most case studies read instead like a slideshow of final screens with captions. The fix is a structure that forces you to show decisions, and a habit of collecting evidence during the work.
The template
1. The problem, in one sentence. "New users of a budgeting app abandoned setup before linking a bank account." Not the company history. The problem.
2. Your role. "Lead designer, with one PM and two engineers, over eight weeks." Readers want to know what you did.
3. Constraints. Deadlines, technical limits, regulation, existing design system. Constraints are what make choices interesting; without them every decision looks obvious.
4. What you learned. Research, analytics, support tickets, competitor review. Show the two or three findings that shaped the work, not every sticky note.
5. References and patterns. What others had done. A small grid of competitor screens with captions such as "most competitors ask for bank access first; two delay it until value is shown" is persuasive and fast to read. A UX competitive analysis gives you this section almost for free.
6. Options. Two or three directions you explored, with sketches or low-fidelity frames. Why each was considered.
7. The decision. Which direction won and why. This is the heart of the case study.
8. The result. Final screens, then the outcome: metrics, test results, or qualitative feedback.
9. Reflection. What you would change. One honest paragraph signals seniority more than any polished screen.
Write captions, not paragraphs
Most readers skim images and captions. So every image needs a caption that says what to notice: "Moving bank linking after the first budget lifted completion." If someone reads only your captions, they should still understand the story.
Collect the evidence during the project
Sections 4, 5 and 6 are where case studies are usually thin, because the material is gone by the time you write. Save as you go: the competitor screens, the analytics chart, the whiteboard photo, the rejected frames. Keep them in one place with a line on why each mattered. GetRef reads every screenshot you save, including the text inside it, so "bank linking competitor" finds the right screens months later. Collections keep each project separate.
Common mistakes
- Starting with the company backstory instead of the problem.
- Writing "we" throughout so your role is invisible.
- Showing only final screens.
- Claiming metrics you cannot explain.
- Ending without a reflection.
A quick self-review
Read only your headings and captions. Do they tell the story? If yes, the case study works. If no, rewrite the captions before touching the body text. For how it fits into the whole portfolio, see UX portfolio examples.
Common questions
- How long should a UX case study be?
- Long enough to show your reasoning and short enough to read in five to eight minutes. That is usually 800 to 1,500 words with a dozen well-captioned images.
- What if I have no results or metrics?
- Say so and use what you do have: usability test findings, stakeholder feedback, adoption by the team, or what you learned. An honest qualitative outcome is better than an invented number.
- Can I write a case study for a concept project?
- Yes, especially early in your career. Be clear that it is self-initiated, give yourself real constraints, and show research with real users, even five conversations.
