To write a UX case study, open with the outcome in one line, state the problem in plain language, name the constraints you were handed, say exactly what you did and what you did not do, walk through two or three decisions and the reasoning behind each, and end with an honest result. Most case studies land between roughly 800 and 1,500 words with a handful of images, which is about a five minute read. The reader is not grading your visuals. They are checking whether you can find the real problem and defend a choice, so every section should earn its place by showing judgment.
The definition
What a UX case study actually is
A UX case study is a short written account of one project, told from the inside, that shows how you moved from a messy problem to a shipped decision. It is not a gallery of the screens you produced, and it is not a diary of every workshop you sat through. It is closer to a legal argument than to a lookbook: here was the situation, here is what I did about it, here is the evidence that it was the right call, and here is what I got wrong.
That framing matters because it tells you what to cut. If a paragraph or an image does not advance the argument, it goes. The mood board that led nowhere, the persona template you filled in because the course told you to, the fourteen wireframe variants you drew before lunch: none of it is evidence. A single sentence explaining why usability testing killed your favorite idea is worth more than all of it.
The people reading it are design leads, hiring managers and sometimes a recruiter doing a first pass. They are looking for signals of judgment, not craft. Craft they can see in one screenshot. Judgment only shows up in prose, which is why the case study exists at all and why designers who write clearly get more interviews than designers who only ship pretty frames.
The structure
How to structure a UX case study, section by section
This is the spine, top to bottom, with a rough word budget for each part. Follow the order. It is the order a reader who has three other tabs open will actually read in.
Open with the outcome. About 25 words.
One line at the very top that says what changed. "We cut a five step signup to two and doubled the number of people who finished it." A reader decides in seconds whether to keep going, so give them the payoff first and make them curious about how you got there.
State the problem, not the task. About 80 words.
The task was "redesign onboarding." The problem was "people who came for one feature had to configure four before they saw anything work." Write the problem in the words a user or a stakeholder would use. If your problem statement is really just a description of the feature you built, you have not found the problem yet.
Name the constraints you were handed. About 60 words.
A three week deadline. A design system you could not fork. No research budget, so you used support tickets as your data. A legal rule that forced an extra confirmation step. Constraints are the most under-written part of most case studies and the part experienced leads read hardest, because real design happens inside limits and fictional design does not.
Say what you did, and what you did not. About 40 words.
One plain paragraph. "I owned the flow and the interaction design. A researcher ran the interviews, and a colleague built the visual system." Nobody is impressed by a solo hero on a team project. They are impressed by a designer whose ownership claims hold up under questioning.
Show two or three decisions, with the trade-off. 300 to 500 words.
This is the case study. Pick the moments where the design genuinely turned, and for each one write what you were choosing between, what evidence you had, what you chose and what you gave up. "We picked one long form over a wizard because the drop-off happened between steps, not inside them." The trade-off is the proof of thought.
Use images as evidence, not decoration. 4 to 8 images.
Every image gets a caption that says what it made you do. A screenshot of the old flow with the failure point circled. The one sketch you abandoned, and the finding that killed it. A before and after of the screen you actually shipped. If you cannot write a caption that carries an argument, the image is filler.
Report the result, honestly. About 80 words.
Numbers if you have them: completion rate, time on task, support volume, error rate. If you do not have numbers, say so and give the qualitative truth instead. "It shipped to all users and became the pattern the other teams copied" is credible. An invented percentage is not, and interviewers will ask you where it came from.
Close with what you would change. About 60 words.
One honest paragraph on the miss. The research you skipped. The edge case that bit you in week two. Naming your own mistake is the single fastest way to read as senior, because it proves you evaluated the work after it shipped instead of just shipping it.
The length
How long should a UX case study be
The working range is roughly 800 to 1,500 words with four to eight images, which reads in about five minutes. Under 800 words you almost never get to a real trade-off, and the piece reads like a project summary. Past 1,500 you are usually padding: every research artifact, every persona, every workshop photo, and a reader who was interested at the top has already left.
Length is a symptom, not a target. A case study gets long for one of two reasons: you have not decided which decisions matter, or you are using volume to hide the fact that you did not make any. The fix is not to trim adjectives. The fix is to pick the two or three moments that actually changed the design and delete the rest of the timeline.
One practical test. Read it aloud. If it takes longer than five or six minutes, it is too long for a first read, and the first read is the only one you are guaranteed. Save the deeper detail for the interview, where someone is actually asking. A case study is a trailer for a conversation, not the whole film.
The failure modes
Five ways a UX case study dies
Almost every rejected case study fails in one of these ways. Read yours against the list before you publish it.
The gallery
All screens, no reasoning
Twelve mockups on device frames, three words of caption. It proves you own Figma. It proves nothing about how you decide, which is the only thing being assessed.
The essay
All process, no decision
Every workshop, every sticky note, every persona, in order. The reader hunts for the thinking and concludes there was not much of it. Process without a turning point is just a schedule.
The we
Ownership you cannot defend
A whole case study written in "we" leaves a lead unsure what you personally touched. They will ask in the interview. If the honest answer is small, say so up front and let the reasoning carry you.
The number
A metric nobody believes
A 200 percent lift with no baseline, no time window and no method reads as invented. One believable qualitative outcome beats a suspicious figure that collapses under a single follow-up question.
The template
Copy that reads like a fill-in form
When the headings are generic and the sentences could belong to any project, a lead recognizes the template immediately. Structure should be borrowed. Voice and evidence cannot be.
The interview
How to present a UX case study in an interview
A portfolio review is usually ten to twenty minutes per project, and it is a conversation, not a recital. Plan it as a walkthrough with room to be interrupted.
Set the scene in a minute.
Company, product, who the users were, what was broken, and what your role was. Do not read the page you already sent them. If they have it open, they can see it. Give them the version you would tell a colleague at lunch.
Spend most of the time on one decision.
Pick the hardest call in the project and take them through it properly: the options, the evidence, the disagreement, the choice. Depth on one decision beats a tour of the whole timeline, and it gives your interviewer something real to push on.
Invite the pushback.
Say the words. "Tell me where you would have gone the other way." A candidate who can hold a disagreement without getting defensive is showing exactly the behaviour that critique demands. Rehearsing an uninterrupted monologue trains the wrong muscle.
Have the numbers, and their limits, ready.
Know where each figure came from, what the baseline was, and what it does not prove. If a number is under NDA, say that plainly and describe the direction instead. Getting caught out on a stat you cannot source is the fastest way to end a portfolio review badly.
End on the reflection.
Close with what you would do differently and what you took to the next project. It leaves the room with the impression that you are still getting better, which is the thing they are actually buying.
The last mile
Where the finished case study should live
Writing it is the hard part. Then it needs an address. The place you put it decides whether a hiring manager reads it in one click or never opens it at all.
| Capability | Folio | A PDF attachment | A Medium or Notion post | Behance or Dribbble |
|---|---|---|---|---|
| How the reader gets to it | One link, opens in the browser, works on a phone | A download, often 20 MB, often opened later or never | One link, on a domain that is not yours | A project page inside a feed you do not own |
| Who owns the URL | You do, on your own domain with a Pro plan | Nobody. A file is not a URL | The platform. Your name is the byline, not the domain | The platform, and it can change the layout under you |
| Control over the page | Block based pages: text, images, galleries, embeds, in your order | Whatever your slide tool exported | One column, their typography, their font size | Their grid and their frame around your work |
| Search and sharing | Per-page SEO title, description and social preview you set yourself | Not indexable. Cannot be shared as a link | Indexed, but the platform outranks you for your own work | Indexed inside the network, tuned for their discovery, not yours |
| Knowing it was read | First-party analytics on every page you publish | Nothing after you press send | Their stats, on their terms | Views and appreciations, which are not the same as a hiring signal |
| A ready-made template | No. Folio does not hand you a case study template | Plenty of decks to copy | Community posts you can imitate | Endless examples, which is why they all look the same |
The template row is not a typo. Folio structures and hosts the page. The argument inside it has to be yours, and that is the only part a hiring manager is grading.
The Free plan, stated plainly
What publishing a case study on Folio actually costs
Here is the honest shape of the free tier before you sign up for anything.
The honest bit
What Folio does here, and what it does not
Folio does not write your case study and it does not give you a template to fill in. There is no downloadable Figma file, no Notion board, no fill-in-the-blank structure that turns a thin project into a strong one. If that is what you came for, the internet has thousands of them, and the reason they all produce case studies that look identical is that a template can only give you headings. It cannot give you a decision you actually made.
What Folio does is the last mile. You write the argument, then you build the page: a block based custom page with your text, your images, your galleries and your embeds, in the order you choose. You set the SEO title, the description and the social preview for that page, so when you paste the link into an application or a message it looks like a piece of work rather than a bare URL. On a Pro plan it sits on your own domain. On Free it lives at portfolio.wrxstack.com under your handle, with Folio branding on it, which is a real trade and we would rather you knew it before you signed up.
Alongside it you get the rest of the surface a designer job hunt needs in one account: the portfolio itself, a resume you can export to PDF or DOCX for nothing, a cover letter to match, and first-party analytics that tell you the case study you were nervous about is the one people actually read. The writing is still the job. Nothing hosts its way out of a project you have not thought hard about.
Frequently asked questions
What is a UX case study?
It is a short written account of one project that shows how you got from a messy problem to a shipped decision. It covers the situation you walked into, the limits you worked inside, the calls you made and why, and what happened afterwards. The point is to expose your judgment, not to display your screens.
What should a UX case study include?
Six things: a one-line outcome at the top, the problem in plain language, the constraints you were handed, an honest statement of what you personally did, two or three decisions with the reasoning behind each, and a result you can defend under questioning. A closing paragraph on what you would change is what makes it read as senior.
How long should a UX case study be?
Around 800 to 1,500 words with four to eight images, which is roughly a five minute read. Below that you rarely reach a real trade-off. Above it you are usually padding with artifacts, and a busy hiring manager stops reading long before the interesting part.
What does a good UX case study look like?
It reads like an argument. The payoff is at the top, each image carries a caption that says what it made you do, two or three decisions are examined properly, the numbers come with a baseline, and the writer admits one thing they got wrong. It does not look like a mood board with paragraphs between the pictures.
How do you present a UX case study in an interview?
Set the scene in a minute, then spend most of your time on the single hardest decision: the options, the evidence, the disagreement, the choice. Ask the interviewer where they would have gone the other way, know where every number came from, and close on what you would do differently. It is a conversation you invite people into, not a recital.
Where should I publish a UX case study, and does Folio give me a template?
Publish it as a page you control, at a link that opens in a browser, rather than as a file somebody has to download. Folio does not hand you a case study template. It gives you a block based page for the finished piece, per-page SEO so the link previews properly, your own domain on Pro, and analytics so you can see which project people actually read.