A strong UX case study is a short, evidence-led story with four moving parts: the problem and who had it, the constraints you worked inside, the decisions you made and why, and the measurable change that followed. The best examples open with the outcome, spend most of their length on the reasoning behind two or three real decisions, and show the messy middle rather than only the polished final screens. Three tight case studies told this way beat a dozen that only display finished work.
What it is really for
A case study is an argument, not a scrapbook
Most weak case studies fail in the same way: they treat the page as a place to display finished screens. The screens are beautiful, the layout is tidy, and a reviewer still leaves with no reason to hire the person who made them. The reason is simple. A finished screen proves that a design exists. It does not prove that the person reading the page is the one who could have arrived at it, and hiring is a bet on the second thing, not the first.
Treat the case study as an argument instead. The claim you are making is that you can look at a real situation, find the actual problem hiding inside it, work through the constraints, and move a number that someone cared about. Everything on the page is either evidence for that claim or it is clutter. A screenshot with no decision attached to it is clutter. A sentence explaining why you rejected the obvious approach is evidence, even with no image beside it.
This reframing changes what you spend your effort on. You stop polishing the fortieth screen and start writing the two paragraphs that explain the one decision that mattered. A reviewer who has read fifty portfolios this week can feel the difference immediately: one page is trying to look impressive, the other is trying to be understood, and only the second reads as the work of someone senior.
The anatomy
The four parts every strong case study has
Titles vary, and you should write your own rather than pasting a template. Underneath the headings, the strong examples all carry these four loads.
Problem
The situation and who was stuck
Name the real problem, the person who had it, and the cost of leaving it alone. A brief is not a problem. "Redesign the checkout" is a brief; "one in three carts was abandoned at the address step on mobile" is a problem a reader can care about.
Constraints
The box you had to work inside
Time, platform, an existing design system, a legal requirement, an engineering budget. Constraints are not excuses. They are what make a decision interesting, because a choice with no constraints is not a decision, it is a preference.
Decisions
What you did and what you rejected
This is the bulk of the page. Walk through two or three real forks: what you tried, what the evidence said, what you chose, and what you deliberately did not do. The path not taken is often the most convincing part.
Outcome
What changed, measured honestly
Tie the work to a number or a clear qualitative signal, and say how you know. If a metric moved, name the baseline. If nothing shipped, say what you learned and how it changed the next decision. Honesty here reads as seniority.
Worked example
Framing the problem so a stranger cares in one line
Consider a real-feeling example: a scheduling tool for home healthcare visits. A weak opening reads, "I was asked to redesign the scheduling flow." A reviewer learns nothing from that, because it describes the assignment rather than the situation. Compare a stronger opening: "Coordinators were double-booking nurses because the calendar showed availability in one place and travel time in another, and every double-booking meant a patient waited." Now the reader can see the person, the failure, and the stakes in a single sentence.
The move that makes the difference is naming the person who was stuck and the cost of the problem. Notice that neither of those requires a screenshot. It is a sentence of context, and it is the sentence most portfolios skip because the writer already knows the context by heart and forgets that the reader does not. The reader is a busy stranger who will give you a paragraph before deciding whether the rest is worth their time.
A good problem statement also quietly frames the outcome you will claim later. If you open by saying that double-booking made patients wait, you have set up a finish line: fewer double-bookings, or a shorter wait. The problem and the outcome are the two ends of the same thread, and when they match, the case study feels like an argument that closes rather than a story that trails off.
Worked example
Showing process without narrating every screen
The middle is where most case studies bloat. The goal is not to prove you followed a process. It is to show the reasoning behind the two or three choices that actually shaped the result.
Pick the decisions worth defending.
From the whole project, choose the two or three forks where a reasonable designer could have gone the other way. Skip the parts where there was only one sensible option. A decision with an obvious answer is not a decision worth a reader minute.
For each, show the fork, not just the winner.
State the options you weighed, the evidence you had, and why you chose as you did. Keeping the sketch of the approach you rejected, with a line on why it lost, is often more persuasive than any polished final frame.
Let the artifacts earn their place.
A flow diagram, a usability-test clip, a before and after: include each only if it advances the argument. If an image does not change what the reader believes, cut it, however nice it looks. Depth on three screens beats a tour of thirty.
Write the headings so they tell the story alone.
A reviewer skimming only your section headings should still land on the point. "We split availability and travel into one view" carries more than "Ideation". Assume the headings are the only thing many readers will actually read.
Weak vs strong
The same project, told two ways
Nothing about the underlying work changes between these columns. What changes is whether the page makes an argument a reviewer can act on.
| Capability | Folio | Strong version |
|---|---|---|
| Opening line | States the role and the brief: what the team asked for | States the outcome and the problem: who was stuck and what it cost |
| Bulk of the page | A gallery of finished screens with short captions | Two or three decisions defended, with the rejected option shown |
| Process section | Every stage of a named framework, one screen each | Only the choices where a reasonable person could disagree |
| Result | A clean chart with no baseline and no method | A number with its baseline, plus what could not be measured |
| What the reviewer takes away | This person can produce a polished screen | This person can find a real problem and reason it to an outcome |
| Reading time to the point | Buried past the fold, if it appears at all | In the first paragraph, then reinforced by every heading |
Both versions can use the exact same screenshots. The difference is entirely in what the words around those screenshots are asked to do.
Proving the outcome
Measure honestly, then put it somewhere you control
The outcome section is where credibility is won or lost. A reviewer who has read enough portfolios can smell an invented metric, and a suspiciously round number with no baseline does more damage than an honest gap. If cart completion rose, say from what to what, over how long, and how it was measured. If the work shipped but you never got clean data, say so and describe the signal you did have. If it never shipped, name the decision it changed. Every one of those is a legitimate outcome, and stating the limits of what you know is the single clearest seniority signal on the page.
Once the case study reads as an argument, it needs a permanent home. A slide deck or a social post is rented ground; the layout and the reach belong to a platform that can change the rules the day you need it most. A site you control is the only version of the work that keeps working when a feed does not. Folio is one hosted way to do that, and the name is a small joke about the word portfolio itself. One account gives you a portfolio site, a resume with a deterministic ATS score, and a contact inbox for the people who find the work. On the free plan you sit on portfolio.wrxstack.com/yourname with a small Made with Folio badge and the full theme gallery on the paid tier, while the resume export downloads as PDF and DOCX at no cost and with no watermark.
Whatever you build it with, hold the standard constant: every case study is an argument, the reasoning is the content, and the screens are the evidence. Get that right and three projects are enough to carry a whole portfolio.
Frequently asked questions
How many case studies should a UX portfolio have?
Three strong case studies are usually enough, and often better than six. A reviewer reads for depth, not volume, so a portfolio of three projects that each defend real decisions will beat one that displays a dozen at a shallow level. Add a fourth only when it shows a genuinely different kind of problem or context.
What should a UX case study include?
Four things: the problem and who had it, the constraints you worked inside, the two or three decisions that shaped the result along with what you rejected, and the measured outcome with its baseline and method. Everything else on the page is evidence for one of those four or it can be cut.
How long should a UX case study be?
Long enough to defend two or three decisions and no longer. In practice that is a page a reviewer can skim in a couple of minutes and read in full in five or six. Length is not the goal; a reader should be able to get the point from the headings alone and the depth from the body if they want it.
What if I cannot share metrics from my project?
Say so, and describe the signal you did have. Not every project produces a clean number, and inventing one is the fastest way to lose a reviewer who has seen the pattern before. A qualitative outcome, an honest note on what could not be measured, or a decision the work changed are all legitimate ways to close.
Can I write a case study for a project that never shipped?
Yes. A project that stopped before launch can still show that you found a real problem and reasoned through it, which is what a reviewer is buying. Frame the outcome as the decision it informed or the learning it produced, and be direct about why it did not ship. Honesty about that reads as maturity, not weakness.