How to Write a UX Case Study for Your Portfolio

A design portfolio is often the first and most important impression a designer makes on hiring managers and clients. And the heart of most portfolios is the case study: a story about a project that shows not just what you made, but how and why.

Many case studies fall into one of two traps. Some are galleries of polished screens with almost no explanation. Others are long, process-heavy documents that list every sticky note and persona but never make clear what the designer actually decided. This guide explains how to write case studies that avoid both.

Who you're writing for#

Hiring managers and recruiters often review many portfolios quickly. They're looking for answers to a few questions:

• Can this person solve real problems?
• How do they think and make decisions?
• Can they work with others — product managers, engineers, stakeholders?
• Is their craft strong?
• What impact did their work have?

A good case study answers these questions quickly, with depth available for those who want it.

Choose the right projects#

Quality matters more than quantity. Two to four strong case studies usually beat ten shallow ones. Choose projects that:

• Show the kind of work you want to do next.
• Demonstrate a range of skills, such as research, interaction design, and systems thinking.
• Had meaningful challenges and constraints.
• Have outcomes you can talk about.

Projects don't need to be glamorous. A complex internal tool with clear problem-solving can be more impressive than a visually striking concept with no real constraints.

Structure the story#

A clear structure helps readers follow your thinking. A common and effective outline:

1. Overview#

Start with a brief summary:

• The product and context.
• Your role and the team.
• The timeline.
• The problem in one or two sentences.
• The outcome, if you have one.

Some readers will only read this section, so make it count.

2. The problem#

Explain what was wrong and why it mattered — for users and for the business. Include evidence: research findings, metrics, support issues, or stakeholder goals. A clearly defined problem makes everything that follows more meaningful.

3. Constraints#

Real projects have constraints: deadlines, technical limitations, legacy systems, budget, regulations. Describing them shows you can design in reality, not just in ideal conditions.

4. Process and key decisions#

This is the core of the case study. Rather than listing every activity, focus on the key decisions:

• What options did you consider?
• What did you learn from research or testing?
• What trade-offs did you make, and why?
• What changed based on feedback?

Show artifacts that support each decision: sketches, flows, wireframes, test findings. Every image should have a purpose and a caption explaining it.

5. The solution#

Present the final design clearly. Highlight the most important screens and interactions, and explain how they address the problem. Use annotations to point out key details rather than showing dozens of screens without context.

6. Outcome and impact#

Share results where possible:

• Metrics: conversion rates, task completion, time saved, support reduction.
• Qualitative feedback from users or stakeholders.
• Business outcomes, like launches or adoption.

If you don't have metrics, describe what you validated and what you'd measure. Be honest; inflated claims are easy to spot and damage credibility.

7. Reflection#

Briefly share what you learned and what you'd do differently. This shows maturity and self-awareness — qualities hiring managers value highly.

Be clear about your role#

Most product design is collaborative. Be specific about what you did versus what the team did. Use "I" for your contributions and "we" for team efforts. Overstating your role is risky, especially in interviews where you'll be asked detailed questions.

Show your thinking, not just your process#

Listing activities — "I did interviews, made personas, created wireframes, ran usability tests" — doesn't show how you think. Explaining decisions does:

• Weak: "I created wireframes."
• Strong: "Early wireframes put filters in a sidebar, but testing showed most users didn't notice them. We moved the three most-used filters above the results, which made them far easier to find."

Decisions, trade-offs, and lessons are what make a case study memorable.

Make it scannable#

Many readers will skim before deciding whether to read in depth:

• Use clear headings for each section.
• Keep paragraphs short.
• Use captions to explain images.
• Highlight key insights and outcomes.
• Put a summary at the top.

A reader should understand the project's essence within a minute.

Handle confidential work#

Many professional projects are under non-disclosure agreements. Options include:

• Blurring or recreating sensitive screens.
• Changing names and data.
• Focusing on process and decisions rather than final screens.
• Offering to walk through details in person.

Always respect agreements with employers and clients.

Present visuals well#

Visual quality matters in a design portfolio:

• Use high-quality images that are legible at typical screen sizes.
• Show designs in context, such as on device frames, where helpful.
• Keep consistent styling across case studies.
• Avoid huge walls of screenshots without explanation.
• Make sure the portfolio itself is responsive and loads quickly.

Common mistakes#

• Showing only final visuals with no context.
• Describing process without decisions.
• Writing very long case studies without structure.
• Being vague about your role.
• Including too many projects of uneven quality.
• Making claims without evidence.
• Ignoring outcomes entirely.

Tell a story#

A great UX case study reads like a story: a meaningful problem, a designer working through constraints and uncertainty, clear decisions informed by evidence, and an outcome that made a difference.

Choose your best projects, structure them clearly, focus on decisions rather than activities, be honest about your role and results, and make it easy to skim. Do that, and your case studies will show not just what you designed, but the kind of designer you are.