Writing a UX Design case study that shows thinking, not just pixels

Stephanie had a case study that looked finished.

Strong visuals, polished UI...

During my UX portfolio review, I scrolled to a section showing a sign-up form and asked her why she chose three short steps instead of one long page.

She thought about it for a second, but couldn't explain her reasons.

This is quite common.

Most designers think case studies are a slideshow of deliverables.

The reality is each one should prove you make good decisions under constraints.

This article shows how to write a case study so recruiters see your thinking, not just your screens.

And if you also want to find out what recruiters check first, read UX Design portfolio review: What hiring managers look for in 30 seconds.

Why most case studies read like UI galleries

Most advice out there tells you to fill in the same sections: Problem, research, process, solution, results. If you follow that, you'll end up with a UX case study that reads like everyone else.

Think about it, when recruiters scan your case study they want to know:

• What problem mattered
• What you owned
• What options you considered
• What you chose and what you gave up
• What changed because of the work

Everything you share should support those answers.

Write backward, not from deliverables

Most designers write forward: Research, wireframes, final UI, then try to explain it afterward.

Write backward flips that. You draft the parts recruiters care about first, then attach only the visuals that prove each point.

If you are unsure about your portfolio structure, start with portfolio design templates: Start with structure, not style. You can also find inspiration from portfolio design ideas: Layouts and structures that stand out.

Step 1: Build a decision log first

Open a doc and list three to five real decisions from the project.

For each one, capture:

• Situation: What was unclear or tense?
• Options: What paths did you consider?
• Choice: What did you pick?
• Trade-off: What did you give up?
• Result: What happened after (metric, quote, behavior change, or honest learning)?

If you can't fill the trade-off line, you might be describing a deliverable, not a decision.

Step 2: Write the opening from outcome and role

Your first section should answer:

• What changed (or what you aimed to change)
• What you owned
• What constraints mattered

Two to four short lines, not a personal essay.

Bad opening: "This project explores reimagining the mobile experience through human-centered design."

Better opening: "I led the UX on sign-up for a mobile app. The goal was to reduce churn. I focused on user flows and usability testing with PM and engineering."

That opening sets up the decision log that follows.

Step 3: Write one section per decision beat

A decision beat is one section about a single choice you made. For example a situation, your options, what you picked, and why. Each log entry from Step 1 becomes one section in your case study.

Structure each section the same way so recruiters can skim:

1. Name the tension in plain language
2. State options you considered
3. Explain your choice and trade-off
4. Show one piece of evidence (screenshot, quote, sketch, test note)
5. Tie to result or learning

Screens go after the reasoning, not before.

Step 4: Add a short context block, not a process dump

You still need context: Problem, users, constraints, team.

Keep it compact.

One short paragraph is enough, skip listing everything you had to do unless it changed a decision.

Effective writing means ruthless cuts, not more methodology language.

Step 5: Close with reflection and honest limits

One short paragraph:

• What you'd do differently
• What stayed unresolved
• What you learned about the product or your role

That signals maturity better than a perfect hero image.

How the pieces fit together

You write in the step order above. Readers scan in a different order:

1. Opening (outcome, role, constraints)
2. Short context block
3. One section per decision
4. Reflection

Build the decision log first in a doc. Assemble the published case study in the reading order above.

Before and after: Stephanie's sign-up section

Before (screens first):

I did the user research and made personas. Then I wireframed and designed the UI. The final screens are cleaner and feel more modern.

Recruiters reading this learn Stephanie can deliver UI. They still don't know what she decided or why.

After (write backward, decision-led):

The parentheses below label each part of the structure. They are only here to help you see the flow. Your published case study uses the same order without the labels.

• (Situation) Users quit on sign-up. In tests, they weren't sure how the process worked.
• (Options) I thought about one long page or three short steps to help them through the journey.
• (Choice) After testing both, I picked three short steps and added a progress bar so each screen had one job.
• (Trade-off) The flow took more taps, so I moved optional profile questions to after sign-up to keep the first steps light.
• (Result) In the first test, six of eight people finished the three-step flow.
• (Evidence: Add relevant visuals to support your story).

Stephanie kept this section, paired it with screens of the sign-up flow, and could finally answer my question in her next interview.

What to cut from bootcamp-style case studies

Use this cut list before you publish.

• Methodology essays ("I utilized a human-centered design process…")
• Every screen in the file (keep only screens tied to a decision)
• Personas and journey maps with no link to a choice you made
• Research summaries with no "so we decided…" line
• Fake metrics you can't discuss in an interview
• Long timelines that don't explain trade-offs

If cutting hurts, you probably built the story forward from deliverables.

Rebuild from the decision log.

Final takeaway

A strong UX Design case study helps a recruiter follow your judgment, not count your screens.

Start with one project. Open a doc. Log three decisions using the format in Step 1. Turn each entry into one section with one visual. Cut everything that doesn't prove a choice you made.

If you can't explain a trade-off out loud, rewrite or cut it.

If you want a second pair of eyes on whether your case study proves thinking, a UX portfolio review catches weak decisions fast.

If you want mentorship while you rewrite your case studies, Zero to Pro will help you focus on your strengths.

FAQs

What is a UX Design case study?

A UX Design case study is a written project story on your portfolio that shows how you made decisions, what trade-offs you accepted, and what changed because of your work. It uses visuals as evidence, not as the main argument.

How is write backward different from a case study template?

A template tells you which sections to include. Write backward tells you what to write first: A decision log, then opening outcome, then one decision beat per choice with paired evidence. Templates give you boxes; write backward gives you the fill order.

How many decision beats should I include?

Usually three to five per project. Junior portfolios can succeed with three strong decisions. Mid-level designers often need four or five when cross-functional trade-offs matter.

Do I still need research in the case study?

Yes, when research changed a decision. Summarize the insight and link it to the choice. Don't include research artifacts that didn't influence what you shipped.

What if I don't have metrics?

Use qualitative proof: Test quotes, support themes, stakeholder decisions, or behavior you observed. Label estimates honestly if the project didn't ship.

How does this relate to the case study examples I see online?

Many design case study examples online are strong on visuals. Borrow scan-friendly headings and whitespace. Don't copy deliverable order. Copy decision clarity if the example shows options, trade-offs, and results.

Should my case study match how I talk in interviews?

Yes. Write each section so you can retell it in two minutes. Interviewers often pull lines from your case study. If you can't explain a trade-off out loud, rewrite or cut it.