How to Write a UX Case Study That Gets You Hired

You have done great work. You have solved real problems, navigated messy constraints, and shipped products that made a difference. But when it comes to communicating that work to a hiring manager or a potential client, too many talented designers fall at this final hurdle. They submit portfolios full of pretty mockups and before/after comparisons, and wonder why they are not getting callbacks.

The problem is almost never the quality of the work. It is the quality of the story. A UX case study is not a design showcase; it is a demonstration of how you think. Hiring managers are not looking at your final screens and evaluating their beauty. They are reading your case study to understand your process, your judgment, and your ability to communicate both. And that is a completely different skill.

This guide will walk you through exactly how to write a UX case study that gets you hired; what to include, how to structure the narrative, what kills most applications, and what the best case studies in the industry do differently.

What Hiring Managers Are Actually Looking For

Before writing a single word, it helps to understand what is happening on the other side of the screen. A senior UX hiring manager at a product company might review 50 to 100 portfolios for a single role. They spend an average of 3 to 5 minutes per candidate before deciding to proceed or move on. In that time, they are not admiring typography. They are asking four questions.

• Do I understand what problem this designer was solving and why it mattered?

• Can I see how they approached the problem — their research, their reasoning, their decisions?

• Did their work have a measurable impact on users or the business?

• Can this person communicate clearly and concisely — a skill they will need every day in this role?

Everything in your case study should be in service of answering those four questions. For a deeper understanding of what recruiters look for, Google's UX Design Certificate resource on portfolio building and the Interaction Design Foundation's guide on UX portfolios are both excellent references.

The Anatomy of a Strong UX Case Study

The best UX case studies follow a narrative arc, not a process checklist. They tell a story with a beginning (the problem), a middle (the process), and an end (the outcome). Within that arc, there are specific sections that every strong case study includes.

1. A Compelling Opening

Most case studies open with a dry project brief: 'I was tasked with redesigning the checkout flow for an e-commerce platform.' This tells the reader nothing compelling. A strong opening answers: what was the real problem beneath the brief, why did it matter, and what was at stake? Lead with the human or business consequence, not the task.

Instead of: 'I redesigned the checkout flow.' Try: 'Cart abandonment on mobile had reached 87%. For a business doing most of its revenue through mobile commerce, this was not a UX problem — it was an existential one. Here is how we turned it around.'

2. Your Role and the Team Context

Always be explicit about your specific contribution. Hiring managers know that design rarely happens in isolation, and they are evaluating you as an individual contributor. If you worked in a team, describe the team composition and be precise about what you owned. 'I led the research and interaction design for the checkout flow, while a visual designer handled the final UI polish and a content strategist owned the copy' is far more credible and useful than 'we redesigned the checkout experience.'

3. The Research and Discovery Phase

This is where most case studies either earn or lose the reader's trust. If your process section reads like a list of methods — 'I conducted user interviews, created personas, mapped the user journey' — you are describing activities, not thinking. What did the research reveal? What surprised you? What assumption did you hold going in that the research challenged? The insight is what matters, not the methodology.

Show the work: include photographs of sticky notes and affinity maps, screenshots of interview highlights, or excerpts from key findings. Concrete artefacts signal rigour.

Abstract descriptions of a research process signal that you are filling in what you think should have happened, not documenting what actually did.

4. How You Defined the Problem

The jump from research to design is where the most important thinking happens — and the most commonly skipped section in weak case studies. Show how the research informed your problem definition. How did 'users are abandoning the checkout' become a specific, actionable design challenge? What constraints shaped your approach? What did you decide not to solve, and why?

A strong problem framing section reveals your strategic thinking — the skill that separates mid-level designers from senior ones. This is where you demonstrate that you understand the difference between a symptom and a root cause.

5. Ideation and Decision-Making

Show your thinking, not just your output. Include sketches, early wireframes, and — critically — the rationale for the choices you made. Why did you pursue this direction over the alternatives? What did you deprioritise and why? Hiring managers love to see the decisions that were made and the reasoning behind them far more than they love seeing a polished final product arrived at without explanation.

If you ran a design sprint, document the diverge and converge phases. If you presented multiple concepts to stakeholders, show what each represented and how you synthesised the feedback into a clear direction. The messiness of real design work, honestly documented, is far more compelling than a suspiciously smooth linear process.

6. Prototyping and Testing

Describe the prototype you built and the questions you were trying to answer with it. Then describe what you found. What worked? What failed? How did your design change as a result of testing? This section is where you demonstrate intellectual honesty — the willingness to let evidence change your design rather than defending your initial assumptions. It is one of the most telling signals of design maturity.

If you used tools like Maze for unmoderated testing or Lookback for moderated sessions, name them. It signals that you work with real professional tools and understand the difference between different testing methodologies.

7. The Final Solution

Now — and only now — show the polished final design. By this point in the story, the reader understands the problem, has followed your thinking, and is ready to see how it resolved. The final design section should be relatively concise: show the key screens or interactions, explain what each solves, and let the quality of the work speak for itself. Annotated screens are far more useful than plain mockups — a label that says 'simplified to a single step after testing showed users were abandoning at the address form' communicates more than the screen alone.

8. Results and Impact

This is the section most designers skip because they either do not have data or are not sure how to frame it. But it is also the section hiring managers weight most heavily. If you have quantitative outcomes — conversion rate improvements, reduction in support tickets, NPS score changes — lead with them. If you do not have hard data, use qualitative outcomes: what did users say after the redesign? Did the business ship on time? Did the team adopt the design system component you created?

Even a statement like 'the redesigned onboarding flow was shipped to 100% of users six weeks after handoff and received an average satisfaction rating of 4.6 out of 5 in in-app surveys' is concrete and credible. The goal is specificity, not magnitude.

The 7 Most Common Case Study Mistakes That Kill Applications

1. Leading with visuals before establishing the problem — no one cares how beautiful your screens are if they do not understand what they are solving

2. Using passive voice and vague language — 'the team decided' hides your contribution; own your decisions explicitly

3. Showing only the happy path — a process that had no obstacles, pivots, or failures is not credible

4. Writing for designers, not hiring managers — avoid jargon and assume your reader needs context for every acronym

5. Forgetting the outcome — a case study without results is a story without an ending

6. Making it too long — aim for a 5 to 8 minute read maximum; editing is a design skill too

7. Not proofreading — typos in a UX case study signal carelessness with details, which is fatal in a field defined by attention to detail

How Many Case Studies Do You Need?

Quality over quantity, always. Two or three excellent, deeply documented case studies will outperform a portfolio of ten superficial ones every time. Each case study should ideally demonstrate a different facet of your skills: one might showcase your research rigour, another your systems thinking, a third your ability to navigate complex stakeholder environments.

For a practical guide to portfolio depth and selection, UX Collective's advice on portfolio case studies and Figma's guide to building a design portfolio are both worth reading before you start writing.

Where to Host Your UX Portfolio

The platform you choose matters less than the clarity of your case studies, but it does matter. A few guidelines: avoid platforms that make your case studies look identical to thousands of other designers on the same template. Custom-built portfolio sites signal craft, attention to detail, and technical range — all things that matter in a UX role.

Popular options include Notion (simple and fast), Framer and Webflow (more control, beautiful results), and purpose-built tools like UXfolio (designed specifically for UX portfolios). Whichever platform you choose, ensure it works flawlessly on mobile — hiring managers review portfolios everywhere.

Your case study is not a record of what you made. It is an argument for how you think. Make every word count.

A Note on Confidential Work

Many designers work on products where showing the final design would violate an NDA or expose sensitive business information. This should not stop you from writing case studies. Anonymise the client, describe the problem space in general terms, and focus your documentation on the process and methodology rather than the specific product. Most hiring managers understand the constraints of NDA-bound work and will respect a well-documented process even when the final design cannot be shown.

Final Thoughts: Your Case Study Is Your Pitch

Every word of your UX case study is doing one of two things: building the hiring manager's confidence in you, or eroding it. A case study that tells a clear story, documents honest thinking, and shows real impact is not just a portfolio piece — it is a demonstration that you can do exactly what the job requires: take a complex problem, think through it rigorously, communicate it clearly, and deliver something that makes a difference.

At Afrodity Designs, we think about communication the same way we think about design: every element should earn its place, serve the reader, and leave nothing ambiguous. If you are a designer looking for help positioning your portfolio, or a company looking for a design partner who brings this level of rigour to every project, we would love to talk.