Case study guide

How to write a product or UX case study that gets you hired

A great case study is not a project description. It is a window into how you think. Here is the structure, the common mistakes, and the specific elements that make hiring managers want to interview you.

What a case study actually is (and is not)

A case study is not a project history — “I worked on X and we did Y and it shipped.” A case study is a demonstration of your problem-solving process: how you defined the problem, how you decided what to build or design, what tradeoffs you made, how you measured success, and what you learned.

The core principle:the outcome matters, but the reasoning matters more. Interviewers are not evaluating the project — they are evaluating how you think through hard problems.

The 6-part structure that works

Every strong PM and UX case study follows a version of this structure. Use it as a checklist before you publish.

Context and problem

What was the situation? What was broken, missing, or unclear? Who was affected? One paragraph — make it specific and concrete.

Your role and constraints

What did you own? What could you not control? What was the timeline and team?

Research and discovery

What did you do to understand the problem? Who did you talk to? What did you find?

Your approach and decision

What options did you consider? Why did you choose what you chose? What did you trade off?

The outcome

What shipped or changed? What did the data show? What surprised you?

What you would do differently

This section separates strong candidates from weak ones. Everyone learns things. Show that you reflect.

Common case study mistakes

These are the patterns that make hiring managers stop reading. Fix them before you share your work.

Too much 'we', not enough 'I'

Hiring managers want to know your specific contribution, not your team's.

No problem statement

Starting with the solution before explaining what problem was being solved.

No data

'The feature was successful' is not a case study. 'Activation rate increased from 34% to 52% in 6 weeks' is.

Too long

Most case studies should be 500–800 words and 3–5 visuals. If it takes 20 minutes to read, it will not be read.

No point of view

Strong case studies include opinions — 'I believed X because Y, even though the data initially suggested Z.'

The visuals that strengthen a case study

Aim for 3–5 visuals per case study. Each one should show something that text alone cannot. These are the types that consistently work.

Before/after screenshots

Show the state of the product before your work and after. Make the change obvious.

User flow diagrams

Illustrate the path a user takes through the experience. Simplifies complex systems at a glance.

Data charts showing the outcome

A single chart with a clear upward or downward line is worth several paragraphs of explanation.

Wireframe progression

Show early concepts alongside the final design. It demonstrates iteration, not just output.

One 'ugly' artifact

A messy whiteboard or early rough sketch shows real process. Polished-only portfolios read as fabricated.

Next steps

Build your portfolio

Once you know how to write a case study, you need the right projects to fill it. The portfolio projects guide walks you through exactly what to build and how to present it.

Build your portfolio