A UX case study is a short story of one design project: the problem, what you did about it, the decisions you made and why, and what changed as a result. It is the main thing a hiring manager reads in a UI UX design portfolio, and they read it to judge how you think, not how polished your screens look.
This guide covers the structure that works, how to write each part, a worked example, how long a case study should be, and how to present one in an interview. No client work yet? Run a UX audit of an app you use, with a heuristic evaluation against Nielsen's 10 usability heuristics, redesign what you find, and write that up. Naming the UX law behind each decision is what turns an opinion into a reason. New to the field? Start with the UX basics.
Your reader is a busy hiring manager or design lead, often looking at many portfolios in one sitting. Treat them as your user. They want quick answers to four questions: what was the problem, what was your part, what did you decide and why, and what happened.
That is why a gallery of final screens rarely works on its own. Screens show the result, but the reader is hiring the judgment that got you there. A case study makes that judgment visible.
Most strong case studies follow the same order. Use it as a template, and cut any part that adds nothing for this project.
| Part | What to write |
|---|---|
| Summary | Three or four lines at the top: the product, the problem, your role and the result. Some readers stop here. |
| The problem | Who had it, how you know, and why it mattered to the people using the product and to the business. |
| Role and constraints | Who you worked with, how long you had, and what you owned. Say I for your work and we for the team's. |
| Research | What you did to understand the problem, and the two or three findings that changed the design. |
| Key decisions | Two or three decisions: the options you considered, the one you chose, and why. This is the heart of the case study. |
| Outcome | What changed, with real numbers if you have them. If it never shipped, say what testing showed. |
| Reflection | What you would do differently, and what you learned. One short paragraph is enough. |
If you keep your projects in Notion, the UX Portfolio and Case Study Builder is set up in this order, so each project gathers the right material as you go.
Here is how the parts read for one small, made-up project: a note-taking app where the button to add a note sat in the top bar.
The key decision from the example: the add button moved from the hard-to-reach top bar to a large floating button at the bottom, where the thumb already rests.
Notice what does the work: a clear problem, evidence, three options, a reason for the choice, and an honest result. The reason comes from Fitts's Law: big targets that are close are quicker to hit. Naming the principle shows the reader you can make the same call on the next project.
Long enough to show the decisions, and no longer. A reader should get the whole story from the summary and the headings in about a minute, and find the detail underneath if they want it. If a section does not support a decision, cut it.
For the portfolio as a whole, two or three strong case studies usually beat six thin ones. Choose projects that show different strengths, for example one with deep research and one with a hard trade-off, and put the best first.
The decision section is where most case studies are thin, because explaining a design choice clearly is a skill of its own. Every challenge in UX Quest is a small version of it: a real screen, a few options, one choice, and the UX law that explains why. Start with Fitts's Law from the example above, then Hick's Law and the Law of Proximity. Each law page says whether its challenge is free or part of Pro.
Three laws that give you the words for common design decisions. Open one to see the screen and the challenge.
A Notion workspace for portfolio projects, set up in the same order as the structure above.
A UX case study is a short write-up of one design project: the problem, your role, the research, the key decisions and why you made them, and the outcome. It is the core of a UX portfolio.
A summary, the problem, your role and constraints, the research that shaped the design, two or three key decisions with the options you considered, the outcome, and a short reflection on what you would do differently.
Long enough to show your decisions and no longer. A reader should get the whole story from the summary and headings in about a minute, with the detail underneath for anyone who wants it.
Two or three strong ones usually beat many thin ones. Pick projects that show different strengths and put the best one first.
Pick a real product you use, review it against usability heuristics, redesign the biggest problem, test the change with a few people, and write that up with the same structure. Be clear that it is a self-initiated project.
Open with the problem, your role and the result. Then walk through one or two decisions in depth, leave time for questions, and be ready to say what you would do differently.