A case study is not a project diary. Interviewers are not reading to understand what you did — they are reading to understand how you think. Structure it wrong and the most impressive work in your portfolio will still lose you the job.

Start with the problem, not the context

Most designers open a case study with company background, team size, and project timeline. Interviewers skip this. Open instead with the problem: what was broken, who was affected, and what was at stake. A single clear problem statement does more to hook a reader than three paragraphs of scene-setting.

'We needed to redesign the checkout flow' is not a problem statement. 'Drop-off at the address step was 34% higher than the industry benchmark, costing the business an estimated £2.4M annually' is a problem statement. One is a task. The other is a reason to care.

Show your reasoning, not just your output

The most common failure mode in case studies is showing the final design without explaining the decisions that led to it. Interviewers want to see the fork in the road — the moment where you could have gone two ways, and why you chose the one you did. Include the options you considered and ruled out. Include the constraints that shaped your thinking. Include the moment the direction changed and what caused it.

This is especially important for senior roles. At junior level, craft matters most. At senior level, judgement matters more than craft — and judgement is only visible through the reasoning you surface.

The structure that works

A case study that consistently lands in interviews follows a simple arc: problem, discovery, framing, design evolution, outcome. The middle sections (discovery, framing, design evolution) are where most of the reasoning lives. The outcome section ties it back to the problem — did you solve what you set out to solve, and how do you know?

Keep the outcome specific. 'Users responded positively' is not an outcome. 'Task completion at the address step improved from 61% to 89% in usability testing, and post-launch data showed a 22% reduction in checkout abandonment' is an outcome.

Your role and collaboration

Be clear about what you personally did versus what the team did. 'We' is a red flag in a case study — it obscures your individual contribution. Name your collaborators and your relationship with them. Describe how you worked with research, engineering, and product, and what that produced that wouldn't have happened without you. Collaboration is a strength; hiding individual contribution is not.

Length and format

The right length is as long as it takes to tell the story clearly, and no longer. Most case studies are too long because designers feel pressure to justify every decision. Edit ruthlessly. If a section doesn't change what the reader understands about your thinking, cut it. Three focused case studies will always outperform eight sprawling ones.