For UI/UX work specifically, a portfolio of pretty final screens isn't enough — a hiring manager wants to see the thinking behind the screens, using every concept covered across this course. A case study is how that thinking gets shown.
| Section | What it covers |
|---|---|
| The problem | What was broken or missing, and for whom — grounds the whole case study in a real need |
| Research | Personas, journey maps, or other research done (see the earlier lessons in this phase) — even a small, honest amount is worth showing |
| The process | Sketches, low-fi wireframes, and how the idea evolved — not just the final polished screens |
| The solution | The final hi-fi screens and prototype, explained in terms of the problem they solve |
| The outcome | What changed, ideally with a number — or, for a course/practice project, what was learned |
The single biggest gap between a weak and a strong UX case study is process visibility. A case study that jumps straight from "the problem" to "the beautiful final screen" reads as decoration; one that shows messy sketches, a rejected direction, and the reasoning for the final choice reads as real design thinking — which is specifically what a UX hiring process is trying to evaluate.
Every project completed across this course's exercises can become a case study: a persona and journey map from Phase 4, a wireframe and prototype from those same lessons, an accessibility pass and a small component set from this final phase. None of it needs a real client — a well-documented practice project, clearly labeled as such, is a completely legitimate case study.
Fewer, deeper case studies win
3-4 strong, well-documented case studies consistently beat 10 thin ones — the same "quality over quantity" principle covered in this site's Freelancing course's portfolio lesson applies here too.