Writing the case study

Telling a clear story

• ✦Build in real narrative tension instead of a flat list of what you did. A pattern that works: "We assumed X, but we found Y, so we changed direction to Z." The turning points, where your thinking shifted, are the most interesting part of the story, not the steps that led there.
• ✦Orient the reader immediately. Open with a quick snapshot: the project’s scope, your specific role, and the goal, before getting into any tension or conflict. Skipping this tends to produce a vague, rambling background that loses the reader before the story starts.
• ✦Test AI suggestions before you treat them as a solution. Show how you tested them (research, usability testing, an accessibility review) and what changed as a result. It’s the same assumed-X, found-Y pattern, applied to your tools.

Writing for a fast scan

• ✦Use headings that state an insight, not a process step. "We realized users don’t sit together" tells the reader more in five words than a heading like "Research" does.
• ✦Aim for roughly 70% visuals to 30% text. Screenshots and annotations carry more weight than paragraphs explaining them.
• ✦Target around 500 to 600 words total. Cut anything that does not directly explain a decision or contribute to the outcome.
• ✦Annotate your screens directly instead of writing long paragraphs about them. A callout pointing at the actual UI does the job faster than a description of it.

Tone and cutting jargon

• ✦Write like a professional talking through their work, not a report generator.
• ✦Say what the design does instead of using buzzwords like "delightful," "seamless," or "intuitive." Those words tell the reader nothing concrete.
• ✦Translate your work into terms a non-designer would value. Instead of "I improved the flow," say what that improvement did: fewer drop-offs, a faster checkout, less support volume.
• ✦Give your numbers scale. State what a percentage is relative to: the baseline it improved from, the revenue or cost it represents, or how many people it affected, so "increased conversion by 15%" is not left to guesswork.
• ✦Edit anything AI drafted until it sounds like you. Reviewers in UXfolio’s 2026 survey said they spot AI-written case studies by repeated phrasing, buzzwords, and generic headings.

Pacing and detail

• ✦Spend the most space on the "why," not the "how." A blow-by-blow of every tool you used says less than the reasoning behind your key decisions.
• ✦Include only the artifacts that move the story forward. Do not dump every sticky note and wireframe you produced.
• ✦Make each transition between project stages logical. Show how one stage’s findings directly shaped the next decision, rather than jumping between them.
• ✦Lead with the outcome. A before-and-after comparison or a quick result teaser at the very top anchors the reader before they’ve read a word of the story.
• ✦If AI shaped a key decision, show the prompt, the first draft it gave you, and how you reworked it. One before-and-after says more than a list of tools. If it saved you time, say where that time went: more testing, accessibility work, or refinement.

Pick a structure, but you do not need to follow it rigidly

• ✦Double Diamond
  The classic four-phase design process: discover the problem, decide what to focus on, design possible solutions, deliver the final one. It’s a reasonable fallback when you’re stuck on structure, but leaning on it too literally, with headers that just repeat “Discover, Define, Design, Deliver,” reads as textbook and can bore a reviewer who’s seen it many times before.
• ✦STAR
  Borrowed from interview technique: situation, task, action, result. Good for a fast, no-frills version of a case study, especially useful when you need to describe a project briefly (a resume bullet, a portfolio index, an elevator pitch) rather than a full page. Recommended by Meggie Brody (opens in a new tab).
• ✦Three-part story arc
  A hook that pulls the reader in, a journey through your key decisions and trade-offs, and an outcome that shows both the result and what you took away from it. Useful when you want the case study to read more like a story than a report. Recommended in UXfolio’s case study webinar (opens in a new tab) and Biggest Portfolio Mistakes Designers Make Every Time (opens in a new tab).
• ✦Theme-based outlining
  Instead of a chronological walkthrough, organize sections around distinct insights or angles on the same project (for example, “designing for 5 million shoppers” as one section, “rebuilding trust after an outage” as another). Works well for complex projects with several genuinely separate storylines. Recommended in How to write and present UX case studies that get you noticed (opens in a new tab), an approach also used by designers like Buzz Usborne (opens in a new tab).
• ✦CPPPR (Context, Problem, Process, People, Result)
  Walks through the project’s setting, the specific challenge, your decision-making journey, the people involved (users, collaborators, stakeholders), and the outcome. Its distinguishing move is giving “people” real weight, instead of treating design as a solo craft. It also recommends keeping context and problem clearly separate (blending them tends to produce vague, rambling backgrounds), and spending close to half the case study on your process and the paths you deliberately did not take. Recommended by Jess Eddy (opens in a new tab), founder of everyday ux.

Structure framework comparison

Whichever structure you start from, treat it as scaffolding you take down once the story is built, not a set of section headers the reader is meant to notice.

The same goes for AI: do not give it a section of its own. At each stage where you used it, say which tool and what for, so it reads as part of your process, not a separate story.

Do this / not this