UX Case Studies Are Broken. Here's How to Fix Them in 2026.

Last year someone asked me to review their UX portfolio. I opened it, and it said “Empathize” in a big heading with a persona underneath. Then “Define” with an affinity diagram. Then “Ideate” with sticky notes.

I’d seen the exact same structure 40 times that month.

That’s the truth about UX case studies in 2026. The old template is dead. A case study isn’t a process document. It’s a structured argument that you deserve the job, built around one specific project, one real conflict, and one clear outcome. Every paragraph that doesn’t support that argument is dead weight.

The case study wasn’t bad. It was competent. It followed every rule the bootcamp taught. It was also indistinguishable from every other portfolio in the pile. If I swapped the logo and changed the problem statement, it could have belonged to anyone.

That’s the problem. UX case studies stopped being about thinking and started being about compliance. Follow the template. Show the deliverables. Prove you know the process. And somewhere along the way, we all started writing the same story with different nouns.

I did it too. My first portfolio case studies were borderline unreadable. I included every wireframe, every iteration, every sticky note I’d ever touched. I treated my case studies like a project log, not a story. It wasn’t until another designer told me “I don’t need to see everything. I need to see the interesting parts” that I realized I’d built a museum of process instead of an argument for hiring me.

The template is the trap

Here’s what happens. You learn the Double Diamond in bootcamp. Empathize. Define. Ideate. Prototype. Test. It’s a great framework for doing design work. It is a terrible framework for telling the story of that work.

Why? Because the Double Diamond tells someone what steps you took. It does not tell them whether you took the right steps. It does not tell them whether you changed direction when the research didn’t support your assumptions. It does not tell them whether you made a difficult trade-off, fought for a user need the stakeholder didn’t see, or shipped something imperfect on purpose because speed mattered more than polish.

Showing the process proves you were there. Showing your thinking proves you deserve to be there again.

Hiring managers spend 60 to 90 seconds scanning a case study. That’s it. If your structure is predictable, their eyes skip right over it. They see “Empathize” and their brain says “I know this part, scroll down.” They never actually read it. You spent 12 hours polishing those persona cards and nobody saw them.

What actually happened in my case studies

Let me give you a real example. When I was designing the onboarding flow at Sortly, I built a flow that asked new users to add items immediately. Open the app, put things in it. It seemed obvious. I shipped a prototype and ran eight user interviews across two rounds.

Every single person did the opposite. They skipped adding items entirely and went straight to building their folder structure. They wanted the scaffolding before the contents. My entire flow was backwards. I wrote about this in detail here.

In a traditional Double Diamond case study, this moment gets buried. It becomes one bullet point under “Test” or “Iterate.” The most interesting thing that happened in the entire project, the moment my design was proven wrong and I had to rebuild from scratch, gets the same visual weight as the sticky notes from ideation.

That’s insane. That moment IS the case study.

When I rebuilt my portfolio, I stopped writing case studies as process logs and started writing them as stories. The hook isn’t “we followed a user-centered design process.” The hook is “I built the flow. Eight users told me I got the order wrong.” One sentence, and you already know this project has a real conflict, a real insight, and a real outcome. You want to keep reading.

The hero’s journey fits better than the Double Diamond

Look at the Sortly story again. Ordinary world, then a call to adventure, then an ordeal that broke my assumption, then a return with something that actually worked. That’s the oldest story structure there is. It survived because it works on anyone telling a story about a fight worth having.

Joseph Campbell mapped the whole thing in 1949 with a dozen stages, a mentor, a shapeshifter, a threshold guardian. Most of that doesn’t survive a 90-second attention span. Four stages do:

1. Ordinary world. The context before you touched the project. What was normal, what nobody had questioned yet.
2. Call to adventure. The problem that forced the work. A complaint, a metric, a stakeholder ask you couldn’t wave off.
3. The ordeal. The moment your plan broke. Research contradicted you, a build failed, a stakeholder said no and meant it.
4. The return. What shipped, and what changed because you were the one who built it.

Run the Sortly story through it. Ordinary world: an app that assumed people wanted to add items first. Call to adventure: a redesign brief that seemed straightforward. Ordeal: eight interviews telling me I had the order backwards. Return: a flow built around folder structure first, items second, and a synthesis matrix I could point to when someone asked why.

It’s the shape every case study is already trying to take, whether the writer knows it or not. Naming the four beats is what turns an accidental structure into an intentional one.

Stop proving you can follow a process. Start proving you can think.

Here’s the shift that changed everything for me. A case study is not a project report. It’s an argument. The argument is: “I am a designer worth hiring.” Every sentence either supports that argument or it doesn’t.

Process screenshots rarely support it. Hiring managers already assume you know the process. You wouldn’t have made it to the portfolio stage if you didn’t. What they don’t assume is that you can work through ambiguity, defend a decision, recover from a bad direction, or compromise without losing the user.

Those things never live in a “Define” section. They live in the story.

Here’s what I mean, from my own work:

The Sage Product Suite redesign wasn’t interesting because I used Figma. It was interesting because I had to design for an enterprise healthcare product where the data relationships were abstract and the users were clinicians with zero patience for UI friction. Every design decision had to survive a room full of medical experts who would catch any factual error instantly. That’s the story. Not the wireframes. The wireframes are evidence. The story is the case study.

My portfolio itself went through maybe four or five complete overhauls. I cut my case studies in half. Then I cut them in half again. I stopped writing “I learned so much from this project” and started writing “Here’s what broke and here’s what I’d do differently.” One version of my portfolio had case studies so long I couldn’t finish reading them myself. If I was bored, a hiring manager was definitely bored. I wrote about the portfolio-building process here. And if you’re prepping a portfolio presentation, here’s what I learned about that, too.

The Sortly onboarding research was only convincing because of the synthesis matrix. Eight transcripts, nine themes, one table. When the pattern surfaced, I didn’t need a meeting to defend the insight. 100% of users skipped items and built structure first, and I could point straight at the row. The speed of the synthesis is what made the pivot possible. That’s a better story than “we conducted user interviews.”

What I’d tell every designer about case studies in 2026

Lead with the interesting part. If your case study doesn’t have a moment of tension in the first three paragraphs, rewrite it. The tension can be a research finding that contradicted your assumptions, a stakeholder who pushed back, a technical constraint that forced a creative compromise, a deadline that made you choose between good and good-enough. Something went wrong, you responded, the project changed. That’s a story.

Cut it in half. Then cut it again. I am a recovering long-winded Lisa. My first drafts for every case study were 2,500 words minimum. Real talk: I have the attention span of a cat watching a laser pointer, and even I couldn’t read through my own case studies. The ones that actually work on my portfolio are under 800 words of narrative, supported by key screenshots that feel earned, not decorative. If a paragraph doesn’t contain a decision, an insight, or a consequence, delete it.

Personality is the only differentiator left. AI is already being used to screen portfolios. The template-following case study is the easiest thing in the world to generate or skim past. The one thing a machine can’t fake is voice. If someone reads your case study and could swap your name for any other designer and not notice, you haven’t written a case study. You’ve filled out a form.

Show the mess. The most compelling portfolios I’ve seen in the last year show failed iterations, wrong assumptions, and rejected directions. It’s counterintuitive. We want to look polished. But polished reads as fake. When you show a version of the design that didn’t work and explain why, you demonstrate something more valuable than taste: you demonstrate judgment.

The FAANG designers break the rules, and that’s the point. Look at portfolios from designers at top companies. Their case studies rarely follow the bootcamp template. They tell short, specific stories about a single problem they solved. They use screenshots the way a journalist uses photographs: to illustrate, not to decorate. They don’t explain what a persona is. They assume you know.

What “good” looks like in 2026

A good case study in 2026 answers three questions before anyone has to scroll:

Question	What it actually means
What was the actual problem?	Not the project brief. The real, messy, human problem underneath it.
What made it hard?	Constraints, ambiguity, conflicting user needs, technical debt, tight timelines.
What changed because of your work?	Measurable outcome, or at minimum a clear directional result.

If you can’t answer those three questions in 300 words, the case study is hiding from itself.

Process artifacts support those answers. They don’t replace them. A screenshot of your Figma file does not tell me what made this project hard. A persona does not tell me whether the research changed your mind about something. An affinity diagram does not tell me what you fought for and what you let go.

The thing I wish someone had told me

I spent years thinking a good case study was a complete case study. Every step accounted for, every deliverable documented, every phase labeled with the correct design-thinking terminology.

I was wrong. A good case study is a selective case study. It chooses the three things that mattered most and ignores everything else. It trusts the reader to fill in the gaps: they know what a persona is, they know how testing works, they don’t need the glossary.

The hardest part of writing case studies is deciding what to leave out. It always will be. The template is comfortable precisely because it removes that decision. Follow the headings and you’re done.

But comfort is not the goal. The goal is to make someone think “I need to talk to this person.” That doesn’t happen through compliance. It happens through clarity, personality, and the courage to show your work. Not all of it. Just the good parts.

Your case study should sound like you, not like every other designer who took the same bootcamp. And if you’re not sure what you sound like yet, that’s a better thing to figure out than which font to use for your Figma exports.

Interested in how I structure UX research to surface these insights fast? Here’s my interview approach. Or if you’re building a portfolio from scratch, start here.