A strong UX case study is a short argument, not a diary of your process. It states the problem and why it mattered, your exact role, the two or three decisions that shaped the result and what you weighed for each, and what happened after launch. Write it so a hiring manager gets the point from the first screen and the full reasoning in about ten minutes.
What the reader is actually checking
A hiring manager or design lead reading your case study is usually trying to answer a handful of questions, quickly:
- Scope: how big and how ambiguous was the problem?
- Ownership: what did you do, as opposed to your team?
- Judgment: when there were several reasonable options, how did you choose?
- Collaboration: how did you work with product managers, engineers, researchers and stakeholders?
- Craft: is the final interface good, down to the details?
- Communication: can you explain all of this clearly? The case study itself is the evidence.
"Did you follow a textbook process" isn't on the list. Experienced readers have seen plenty of double-diamond diagrams and personas with stock photos, and they skip them to look for decisions.
They also skim first. They read the title and summary, scroll through the images, and only go back to read properly if the project looks relevant to the role. Every page of a UX design portfolio, and above all the case-study pages, has to work for both readings.
A case study structure that works
Use this outline as a starting point, and cut any section that adds nothing for a particular project.
1. A title that says what happened
"Project Atlas" or "Banking app redesign" tells the reader nothing. Name the problem or the outcome: "Cutting checkout steps for repeat buyers in a grocery app", or "A scheduling tool for clinic receptionists who often work offline".
2. A summary block
Four or five short lines at the top that a skimmer can take in at a glance:
- Context: the product, the users and the business situation, in one sentence.
- Role: your title and what you owned.
- Team: who you worked with.
- Timeline: how long it took, and whether it shipped.
- Outcome: the result in one line, measured if possible.
If someone reads only this block, they should still be able to describe the project in an interview debrief.
3. The problem
Describe the user problem and the business problem, and show how you knew they were real: research sessions, support tickets, analytics, feedback from sales. Keep it to a few paragraphs. A clear problem statement makes every later decision easier to judge.
4. Your role
Be exact. "I led the design of the onboarding flow, ran usability sessions with our researcher and worked with two engineers through the build" is far more convincing than a vague "we". Use "we" for team work and "I" for your own, and don't claim anything you didn't do, because interviewers will ask follow-up questions.
5. The process that mattered
Include only the steps that changed the outcome. If a round of testing overturned your first idea, show it. If a competitive review changed nothing, leave it out or give it one line.
6. Key decisions
This is the heart of the case study, and the part most portfolios skip. Pick the two or three decisions that shaped the result, and for each one show:
- the options you considered (sketches or rejected screens help here);
- the constraint or evidence that settled it: a technical limit, a deadline, a research finding;
- what you chose and why;
- what you gave up, and when you'd revisit it.
A rejected direction with a clear reason is often the most impressive image in the whole case study.
7. The outcome
Share results if you have them, and say how they were measured: conversion, task completion, support volume, time on task, adoption. If you can't share numbers, describe the change in words. If the project never shipped, say so and explain what you learned. Readers respect honesty far more than a vague success story.
8. Reflection
Two or three sentences on what you'd do differently. Make it specific ("I'd bring the support team in earlier, because they knew the edge cases") rather than generic ("I learned the importance of communication").
How long should a UX case study be?
Long enough to explain the decisions, and no longer. For a substantial project that's usually somewhere between 800 and 1,500 words plus visuals. A smaller project can work in 300 words and a handful of images.
The trick is layering, so one page serves every kind of reader:
| Reader | What they read | Time it should take |
|---|---|---|
| Recruiter screening many portfolios | Title, summary block, outcome | Under a minute |
| Hiring manager deciding on an interview | Headings, image captions, key decisions | A few minutes |
| Interviewer preparing questions | Everything | Ten minutes or so |
Write headings that carry meaning on their own ("We cut the form from three pages to one" rather than "Iteration 2"), and captions that tell the reader what to notice in each image.
Visuals that carry the story
Every image should prove something the text claims. The useful kinds:
- Before and after: the old screen beside the new one, with the changes called out.
- Annotated screens: callouts that explain a decision right on the interface.
- Flows: the user journey before and after, simplified to what matters.
- Rejected options: two or three directions side by side, with the reason one won.
- Evidence: a clear chart, a short research quote with the participant anonymized, a summary of findings.
Avoid photos of sticky-note walls nobody can read, tilted device mockups that hide the interface, and dozens of full-length screens with no explanation. Crop each screen to the part you're discussing so it stays legible on a phone, where plenty of people will open your link first.
Give each image alt text that says what it shows and why it's there; the W3C's images tutorial explains how. A UX portfolio that ignores accessibility undercuts its own argument.
Handling NDA and confidential work
A lot of designers' best work sits under a confidentiality agreement. You still have options, but read your agreement first, and ask your former employer or client if you're unsure. This isn't legal advice: what's allowed depends on your contract and the country you work in.
- Ask for permission. Many companies allow portfolio use after launch, sometimes with conditions.
- Anonymize. Rename the product, change the brand colors and logo, swap real data for realistic fake data, and remove anything that identifies customers.
- Show the thinking without the screens. Describe the problem, constraints and decisions in words and simplified wireframes.
- Recreate representative screens that show the pattern without copying the real product.
- Keep the detailed version for interviews. Publish a short summary and say you're happy to walk through the full project live.
Never publish confidential numbers. Relative changes ("support tickets about billing roughly halved") are safer, but only if your agreement allows even that.
How many case studies to include
Two to four deep case studies beat eight shallow ones. A reader who's convinced by your first two rarely needs a fifth, and a weak fourth can undo the good impression of the first three.
A balanced set for a mid-level or senior designer:
- A shipped project with measured results.
- A complex or ambiguous problem where your judgment shaped the direction.
- Something that shows range: a design system, research-led work, or a project in a different domain.
Below the case studies, a short "Other work" list with one line per project shows breadth without asking anyone to read more. If you're still studying or just graduating, two or three case studies are enough, one of them can be self-initiated as long as you say so, and this guide to building a portfolio as a student covers what to show with little experience.
If you're moving toward senior product roles, shift the weight from interface craft toward influence: how you shaped the roadmap, aligned stakeholders and defined success. A product designer portfolio puts that judgment first, with project pages built around context, options, decision and result.
Mistakes to fix before you send the link
- The summary doesn't say what your role was.
- Every section gets the same weight, so nothing stands out.
- Process steps appear because a template listed them, not because they changed anything.
- There are no rejected options, so it looks as if your first idea always won.
- Outcomes are vague ("users loved it") with no evidence behind them.
- Images are unreadable on a phone.
- The whole case study is a slide deck exported as images, so none of the text can be selected, searched or read by a screen reader.
Publishing your case studies
Case studies read best as real web pages, with selectable text, images that work at every screen size and a clear route back to your other projects. The UX portfolio builder opens FNJ's AI builder with a starter prompt for UI/UX designers; show it a portfolio whose case-study pages you found easy to read, and it takes the layout and typography, never the words, so you add your own writing and screens. You can then refine any page on the canvas, export the code and host it yourself.
Frequently asked questions
How long should a UX case study be?
For a substantial project, roughly 800 to 1,500 words plus visuals, layered so a skimmer gets the point from the title and summary block. Smaller projects can be much shorter.
How many case studies should a UX portfolio have?
Two to four in depth is right for most designers, plus a short list of other work. A few well-argued case studies are more convincing than many thin ones.
Can I include NDA projects in my UX portfolio?
Often, with care: ask for permission, anonymize the product and data, or describe your decisions without showing real screens. Check your agreement first, because what's allowed depends on your contract and country, and this isn't legal advice.
Should I include projects that never shipped?
Yes, if the thinking is strong and you're honest about why the project stopped. Explaining what you learned from an unshipped project can show more judgment than a shipped one with no story.
What is the most important part of a UX case study?
The key decisions: the options you considered, the evidence or constraint that settled each choice, and what you gave up. That section shows judgment, which is what hiring managers are trying to assess.