Writing a UX case study

Why it matters

Designers are hired on their portfolios, and portfolios are made of case studies. A case study is a short story of one project: the problem, what you did, why you made the decisions you made, and what happened. Hiring managers often skim a case study in a few minutes, looking for evidence that you can think through a problem, not just make attractive screens. Your course project, from interviews to usability test, is exactly the raw material you need.

The core idea: show decisions, not deliverables

A weak case study is a gallery: persona, journey map, wireframes, final screens, with no explanation. A strong one explains why. For each major step, answer: what did I need to learn or decide, what did I do, what did I find, and what did I decide as a result?

A reliable structure:

1. Title and one-line summary. "Splitting house bills without the awkward chase: a mobile concept that cut task failures from 4 of 5 to 1 of 5."
2. Overview. Your role, timeline, tools, team (or "solo course project"), and constraints. Be honest: a course project is fine.
3. The problem. Who has it and why it matters, with research evidence. Include your problem statement.
4. Research. What you did (five interviews), what you found (two or three key insights with counts), and one artefact (affinity map photo or persona).
5. Define. The journey map low point you chose, the flow and the sitemap decisions.
6. Design. Wireframes and prototype, with the two or three most important design decisions and the reasons for them. Show options you rejected and why.
7. Testing. What you tested, the key findings, metrics (task success, SUS with sample size) and the changes you made.
8. Outcome and reflection. What changed between versions, what you would do next, and what you learned.

Worked example: a decision written well

Weak:

I made wireframes for the split screen.

Strong:

Decision: let the app do the chasing. In interviews, 3 of 5 people said asking housemates for money felt like nagging, and the journey map's lowest point was the chase. So the confirmation screen promises an automatic reminder in three days, and the request comes from "the house", not from the person who paid. In testing, 4 of 5 participants said the confirmation made them feel the follow-up "wasn't on them".

The strong version links evidence to a design choice and then to a result. That chain is what reviewers look for.

Showing results honestly

• Use numbers with sample sizes: "Task success rose from 1 of 5 to 4 of 5 after the redesign" or "SUS 62 then 78 (5 participants each round)".
• Course and personal projects rarely have business metrics, and that is fine. Show research and testing outcomes instead.
• Never invent results. Reviewers ask follow-up questions in interviews, and made-up numbers fall apart quickly.
• Say what did not work. "My first card sort used jargon labels, so participants grouped by word" shows you can learn.

Writing and layout tips

• Lead with the outcome. Put the summary and the final design near the top; many readers stop after the first screen.
• Scannable headings for each section, short paragraphs and captions on every image ("Affinity map: 46 notes from 5 interviews, grouped into 4 themes").
• Show artefacts at a readable size. A tiny photo of a wall of sticky notes proves nothing; crop to a readable section.
• Keep it focused. A good case study takes five to eight minutes to read. Cut steps that did not influence decisions.
• Protect privacy. Remove participants' names and faces unless you have permission, and do not share an employer's confidential work.
• Accessible format. Real text, not text baked into images; alt text on images; good contrast.

Where to publish: a free portfolio site builder, a personal site built with HTML and CSS, a PDF, or a free design community profile. The format matters less than the clarity of the story.

Common mistakes

• A gallery of deliverables with no reasoning.
• "We" with no "I". Make your own contribution clear, especially in team projects.
• Hiding the mess. Real projects change direction; showing why is a strength.
• Only final, polished screens. Without the process, reviewers cannot judge your thinking.
• Walls of text. Break it up with headings, visuals and captions.

Quick recap

• A case study tells the story of one project: problem, process, decisions, results, reflection.
• Link evidence to each decision and each decision to an outcome.
• Report honest results with sample sizes; never invent numbers.
• Lead with the outcome, keep it scannable, protect privacy.

Try it

On the Do tab you will write a case study for the project you have worked on throughout this course.