How to write a UX case study

01What a case study is for

A case study shows how a designer thinks, not only how the result looks. Readers want to see the problem, the decisions, the reasons behind them and the outcome. A gallery of screens cannot show any of that.

The usual reader is a hiring manager with a few minutes and many portfolios to review. Write for that person first.

Choose projects that show different skills, and keep the number small. Two or three well-told cases are stronger than ten thin ones.

02A reliable structure

1. Context and problem. Who the product is for, and what was not working. Two or three sentences.
2. Role and team. Your title, the team members, the time frame and what you were responsible for.
3. Process. The main stages, such as research, ideas, prototypes and testing, shown with a few artefacts.
4. Key decisions. Two or three choices, each with the evidence behind it and the alternatives you rejected.
5. Outcome. What changed, with real evidence.
6. Reflection. What you would do differently and what you learned.

The order above is a default, not a rule. Some projects read better when the outcome is stated first. What matters is that a reader can answer three questions quickly: what was the problem, what did this designer do, and what happened.

For each key decision, a useful pattern is: the situation, the options considered, the choice, and the reason. Two or three decisions explained this way show more judgement than a long list of screens.

03Be honest and specific

• You versus the team. Say clearly which parts you did, which were shared and which belonged to others. Keep the wording precise about who did what.
• Unfinished or untested work. If something was never tested or shipped, say so. Readers trust a candid note more than a polished claim.
• Never invent metrics. If you have no measured result, describe what you observed, such as feedback from a usability test, and label it as such.

A modest, true result is stronger than a large number nobody can verify.

Evidence can be modest and still valuable: a quote from a usability session, a before-and-after comparison of a task flow, or a list of issues found and fixed. State where the evidence came from and how many people were involved.

04Make it scannable

• Show process artefacts: sketches, flows, wireframes, research notes. Add a caption saying what each one shows and why it matters.
• Use clear headings, short paragraphs and one idea per image.
• Open with a short summary: the problem, your role and the outcome, in three lines.
• Cut anything that does not support a decision or the outcome.

Respect confidentiality. Blur or replace private data, and check what you are allowed to share before publishing.