How to Write UX Case Studies

Most UX case studies fail for one reason: they describe what happened instead of explaining why it mattered.

Hiring managers read dozens of these. They're looking for evidence that you can define problems, make decisions under constraints, and connect your design work to outcomes. A wall of polished mockups without context doesn't give them that.

Here's a structure that works, and how to fill it out.

The structure that works

A strong case study follows this sequence:

1. Problem statement — what was the problem and why did it matter?
2. Constraints — what were you working with (time, team, tech, budget)?
3. Research — what did you learn before designing?
4. Process — how did you move from research to solution?
5. Decisions — what were the key choices you made and why?
6. Outcome — what happened after you shipped?

This order is deliberate. Constraints before process shows you designed within reality, not in a vacuum. Decisions before outcome shows your reasoning, not just your output.

Writing the problem statement

Make it specific. "The checkout experience had too much friction" is vague. "Cart abandonment on mobile was 73%, compared to 41% on desktop" is specific.

If you have metrics, use them. If you don't, describe the problem in behavioral terms: "Users were calling support to complete sign-up" or "The team was shipping features that users weren't finding."

State who was affected and how. "Small business owners couldn't export their data without writing code" is clearer than "The export feature was hard to use."

Your problem statement should be 2-4 sentences. If you need more than that, you haven't found the real problem yet.

Showing your constraints

Constraints are not excuses. They're context. Showing you understood what you were working within is a sign of professional maturity.

Name your constraints specifically:

• Timeline: "We had 6 weeks before the iOS app launch"
• Team: "I was the only designer; the rest of the team was two engineers"
• Technical: "We couldn't change the database schema, only the frontend"
• Scope: "We were redesigning the settings section, not the full product"

Hiring managers who have shipped real products know that unconstrained design work doesn't exist. They'll trust you more when you show that you understand this.

Documenting research

This doesn't need to be exhaustive. Pick the most influential thing you learned and explain how it changed your thinking.

"We ran 6 user interviews and learned that most users were completing this task on their phone during their commute" is more useful than listing every method you used.

Show artifacts where relevant — an affinity map, key quotes, a user flow showing what you observed. Keep it to 2-3 visuals. The goal is evidence, not documentation for its own sake.

Showing process — messy is fine

You do not need polished early-stage work. In fact, showing only polished work is a red flag — it suggests you either skipped the exploratory process or you're hiding it.

Show:

• Rough sketches or whiteboard photos
• Early wireframes in Figma (low-fidelity is fine)
• Iterations and what caused you to change direction

Explain what each step was for. "These sketches were about exploring different information hierarchies before committing to a layout" is more useful than just showing the sketches.

Two or three iterations with explanations are more compelling than ten polished screens with no context.

Writing about decisions

This is the most important section and the one most designers skip.

For every significant design decision you made, explain the reasoning. Not the "I chose this because it looks better" reasoning — the "I chose this because users were doing X and this pattern solves it" reasoning.

Structure it as: situation → options considered → choice → rationale.

"We considered a modal for this flow, but modal interactions have high dismiss rates on mobile. We went with a dedicated page instead, which kept users in the flow without requiring them to maintain context across a dialog."

You can write this in Notion and refine it there before pasting into your portfolio.

Outcomes — metrics if you have them, qualitative if you don't

If you have quantitative outcomes, lead with them. "Cart abandonment on mobile dropped from 73% to 52% in the first month" is compelling.

If you don't have metrics (common at agencies, startups, or for internal tools), use qualitative outcomes:

• What did stakeholders say after launch?
• Did support tickets decrease?
• What did early user feedback look like?
• What would you do differently?

Acknowledging what you'd change shows self-awareness. It's not a weakness.

What to leave out

Every single screen. Pick the ones that illustrate decisions. Readers will not look at every screen — they'll skim and stop when something catches their attention.

Jargon-heavy methodology descriptions. "I utilized a double-diamond design process to triangulate insights from a mixed-methods research approach" tells a hiring manager nothing useful. Just describe what you actually did.

Fake projects you didn't care about. If you redesigned an app you've never used for a spec work challenge and felt nothing about it, it will read that way. Do projects that had a real problem you genuinely wanted to solve.

Results you can't back up. Don't write "improved user satisfaction by 40%" if you're guessing.

Hosting your case studies

Framer is the best option for a polished portfolio site with inline case studies. The CMS handles multiple case study pages, animations are easy to add, and it looks good out of the box.

Notion works for early career designers who want to move fast. It's not as visually impressive, but it's better to have something live than to spend months building a custom Framer site.

Build your portfolio in Framer

A good case study is 800 to 1200 words with 6 to 10 carefully chosen visuals. Long enough to show depth, short enough to hold attention. Most designers write too much. Edit down.