Design

How to Write a UX Case Study: Structure, Examples, and the Mistakes That Sink Them

By Dan Kovac · 9 min read

A UX case study is a short story about a design problem: what you were handed, what you decided, and what happened as a result. The strongest ones lead with the outcome, show two or three real decisions (including the options you rejected), and close with honest numbers. Aim for something a hiring manager can skim in two minutes and read in eight.

That last part matters more than most guides admit. Nobody reads your case study top to bottom on first contact. They skim it, form a judgement, and only then decide whether to read properly. Your job is to survive the skim.

What is a UX case study?

A UX case study is evidence of judgement. Not a diary of your process, not a gallery of your screens. It is a demonstration that you can take an ambiguous problem, make defensible decisions under real constraints, and tell the truth about how it went.

Hiring managers open your portfolio with one question: can this person think? Screens alone can't answer it. A beautiful final UI tells them you (or your team, or your design system) can produce polish. It says nothing about whether you chose the right problem, killed your weaker ideas, or noticed when the data disagreed with you. The case study is where that shows up.

Which is why the format is worth taking seriously. The same project, written two different ways, reads as two different designers.

What structure should a UX case study follow?

Seven beats, in this order. The order is the point: outcome first, process in service of decisions, reflection last.

1. Hook and outcome (the first screen)

Reviewers decide whether to keep reading based on what fits on one screen without scrolling. So put the ending there: one or two sentences on what the project was and what changed because of it, next to your strongest visual.

Weak: "A redesign of the onboarding flow for a fintech app."

Strong: "Rebuilt onboarding for a fintech app after 60% of signups stalled at identity verification. Completion rose from 40% to 68% in the quarter after launch."

If a recruiter reads only that, they already know you ship things that move numbers. Everything below the fold is now optional, which paradoxically makes it far more likely to get read.

2. Context

Two or three sentences: what the product is, who uses it, your role, the team, the timeframe. Be precise about what you personally did. "I led research and owned the checkout flow; a senior designer owned the design system" is more credible than an implied solo effort, and interviewers will probe it anyway.

3. Problem framing and research

Open with the problem as you eventually understood it, then show the one or two pieces of evidence that got you there. Not every interview, not the full affinity map, just the finding that changed your mind. "We assumed users abandoned verification because it was slow. Session recordings showed they abandoned when asked for a physical document they didn't have to hand" is one sentence of research doing more work than ten synthesis screenshots.

4. Constraints

This is the most skipped beat and the one senior reviewers look for hardest. Real design happens inside limits: a legacy backend, a legal requirement, six weeks, no engineering capacity for the ideal version. Naming your constraints does two things. It explains why the final design looks the way it does, and it signals you've worked on real products rather than unconstrained concepts.

5. Design decisions, with the roads not taken

The heart of the case study. Pick two or three genuine decision points and, for each, show what you chose, what you rejected, and why.

"We considered a progress bar, a checklist, and a single adaptive screen. We killed the progress bar because verification length varies too much to promise progress honestly."

That is the sentence that gets you an interview, because it is the kind of thinking the job actually consists of. Finals-only case studies fail here. If you show only the polished end state, a reviewer can't tell whether you made the decisions or inherited them.

6. Outcome, with honest numbers

Report what actually happened, including the parts that didn't work. "Completion rose from 40% to 68%. Support tickets about verification dropped by a third. Time-to-first-transaction didn't move, which surprised us" is more persuasive than a wall of wins, because it reads like someone who checked.

If the project never shipped, say so plainly and report what you can: usability test results, stakeholder decisions it informed, what would have been measured. Honest absence of numbers beats invented ones.

7. Reflection

Two or three sentences on what you'd do differently. Not false modesty ("I'd manage my time better") but a real design judgement: "I'd test the adaptive screen with older users earlier; we caught an accessibility issue two weeks before launch that research would have surfaced in week one."

The first-screen checklist

Before publishing, check the top of your case study answers these without scrolling:

• What was it? One sentence of context.
• What was broken? The problem, in the user's or business's terms.
• What changed? The outcome, with a number or an honest proxy.
• What am I looking at? Your strongest visual, not a mood board.
• Who did it? Your actual role.

If you want the full skeleton with prompts for each beat, we've broken it into a fill-in-the-blanks structure in our case study template.

What mistakes sink most UX case studies?

Five patterns account for most rejected portfolios. All are fixable.

Process worship. Thirty screenshots walking through every stage of the double diamond, ending in one screen of final UI. Process artefacts are means, not evidence. Show the two research findings that changed a decision; cut the rest. A reviewer who wants your full Miro board will ask in the interview.

No numbers, or vanity numbers. Zero metrics reads as "didn't check". But "increased engagement by 300%" with no baseline, no timeframe and no definition reads worse: it reads as invented. A modest, specific number ("checkout errors fell from 12% to 7% of sessions over eight weeks") beats a spectacular vague one every time.

Finals only. Polished screens with no visible decisions. This is the portfolio equivalent of handing in the answer without the working. It also makes your work indistinguishable from anyone else using the same design system.

Walls of text. Case studies are skimmed. Long unbroken paragraphs, no headings, no pull-out numbers means the skim fails and the reader leaves. Write headings that carry meaning on their own, keep paragraphs short, and let one strong image per beat do the heavy lifting.

Five identical concept redesigns. A portfolio of unsolicited Spotify, Instagram and Airbnb redesigns tells a reviewer you've never worked inside real constraints, five times over. One concept project, honestly labelled, is fine. A portfolio of them is a red flag. If you lack shipped work, a small real project (a local business, a nonprofit, your own tool) outweighs another imagined redesign of a product with a hundred-person design team.

Where should your UX case studies live?

On a domain you control, with the case studies as proper pages, not slides, not a feed post, not only a PDF.

Behance and Dribbble have a real use: visibility inside the design community. But they place your work in an infinite scroll next to hundreds of competitors, the platform controls the presentation, and the audience skews designers rather than the hiring managers and founders who make decisions about you. A recruiter who lands on your own site sees only you, reads case studies formatted the way you intended, and finds you again next time they search your name.

The practical bar is lower than most designers assume. You don't need to design and build a custom site (though you can). You need a clean page per case study, a short profile, and a URL you'll still own in five years. Whatever tool you use, own the ground you're standing on.

There's a career argument underneath this too. The point of being findable is not reach for its own sake; it is that the trail of decisions in your case studies is doing the arguing while you sleep. Referred and known candidates convert from application to interview at roughly 40%, against about 3% for cold applications (Ashby, across 38 million applications). A findable, well-organised body of work won't guarantee you anything, but it changes which side of that funnel you're on: it gives people a reason to already know how you think before you apply, when a competitor's judgement is still invisible.

FAQ

How long should a UX case study be?

800 to 1,500 words, readable in five to ten minutes. Shorter and you can't show decisions; longer and you've stopped editing. The skim version (headings, first screen, pulled-out numbers) should work in under two minutes on its own.

How many case studies do I need?

Three strong ones. Two is workable if both are excellent. Beyond four or five, reviewers stop reading and weaker entries dilute stronger ones. Cut ruthlessly: your portfolio is judged by its worst case study, not its best. For the rest of what belongs around them, see what to include in a portfolio.

Can I use bootcamp or concept projects?

Yes, with honest labelling. "Concept project completed during a UX bootcamp, not shipped" costs you nothing; a reviewer discovering the truth mid-interview costs you the interview. Strengthen concept work by imposing real constraints on yourself and testing with actual users, then showing those results.

How do I handle work under NDA?

Abstract the specifics, keep the thinking. Recreate sanitised screens, describe the problem in general terms ("a b2b logistics platform"), and report metrics as relative changes ("reduced task time by roughly a third") rather than raw figures. Say clearly that details are altered for confidentiality. If in doubt, ask your former employer: many approve more than designers expect.

Do I need metrics if the project never shipped?

No, but you need honesty. State that it didn't ship and why, then report what evidence you do have: usability test results, before-and-after task success in prototypes, or the decision your work informed. Never invent post-launch numbers for pre-launch work.

A good case study isn't written once. It's the record of work you're doing anyway, kept current a little at a time: ten minutes a month updating outcomes and adding new decisions keeps it alive between job hunts, which is exactly when the next opportunity tends to arrive. If you want a home for that habit, Flexfolio is built for designers who'd rather tend a portfolio than rebuild one every two years: your case studies, profile and writing wired together on one link, live in minutes.