The UX Case Study Checklist (Recruiter's Point of View)

Use this UX case study checklist as a final pass before you publish or share your work. It is written from the point of view of a hiring reviewer scanning many portfolios, so it focuses on whether your thinking is clear — not whether your screens are pretty.

Most case studies fail because the reasoning behind them is hard to follow. This checklist exists to catch that before a recruiter does. For the full reasoning behind each item, see the UX case study guide.

The test behind every item: could a reviewer who spends two minutes on your case explain, in their own words, what you did and why it was reasonable?

Before you start

If you can’t answer these three, fix that first — no structure will save a case study that skips them.

• Who is this case study for? (junior or mid-level role; product company or agency)
• What was your specific role? (“worked with the team” is not a role)
• What problem does this case prove you can solve? (not which screens you designed)

Section-by-section checklist

Context

• Product or platform is clear
• Target users are named
• The business or user problem is stated
• Constraints are visible (time, tech, data, team)

One short paragraph is enough. This is context, not a story.

Problem statement

• Specific and concrete, not “improve the UX”
• Written in plain language
• Tied to a real user or business pain

Your role

• What you owned
• What you collaborated on
• What you did not do

Reviewers scan this first to assess your level. Naming what others did makes your contribution more credible.

Research and insights

• The methods you used, briefly
• Why those methods fit the problem
• Key insights, not raw data

Ask yourself: can someone understand what you learned in ten seconds? Avoid dumping survey questions, sticky-note photos, or obvious findings.

Decision-making (the most important section)

• Your key design decisions are stated
• The alternatives you considered are shown
• The reason you chose one over the others is clear

This section proves how you think, not how well you use Figma.

Design execution

• The path from wireframe to final flow shows only what’s relevant
• Every screen has context
• Changes are explained, not just displayed

Outcomes and impact

• What changed after launch (if it shipped)
• Metrics, if you genuinely have them
• Qualitative evidence if metrics aren’t available
• Limits stated honestly — no invented numbers

It’s fine if results are limited. Explain what you’d measure next. See how the example case studies handle honest, scoped results.

Reflection

• What worked
• What didn’t
• What you’d do differently next time

This shows maturity more than perfection.

Red flags to remove before publishing

• Too long, with no clear hierarchy
• Screens shown without explanation
• Generic UX jargon instead of real reasoning
• No clarity on what you personally owned
• Reads like a design exercise, not a real problem
• More focus on visuals than on thinking

If a recruiter has to work to understand your case study, they’ll move on.

The 30-second final scan

Before you hit publish, read your case the way a reviewer will:

• Can I understand the problem in under 30 seconds?
• Is your role crystal clear?
• Do I see how you think, not just what you made?
• Would I trust you with a real product problem?

If most answers are yes, your case study is doing its job. If you’re starting without a client project, read how to write a UX case study with no experience first.