Why Your UX Case Study Feels Weak Even If the Project Was Good

I’ve spent the last decade evaluating designers. First as a mentor and educator, the last 5 years on the hiring side. The pattern that keeps surprising me is how often a strong project gets buried under a weak case study. Real work, real outcomes, real complexity. And the reader walks away not really sure what happened.

Most of the time, what’s missing is the thread that connects what’s already there.

What’s actually going wrong

Most weak case studies share one specific issue: the reader can’t follow the reasoning.

You can see the screens. You can see the artifacts. What you can’t see is why the designer made each decision. Without that thread, the work looks like a collection of activity. And for a hiring panel skimming twelve portfolios on a Sunday afternoon, that thread decides whether you get the call back.

The thing is, the designers writing weak case studies are often the ones who did the most rigorous work. They have the receipts. They just don’t put them on the page, because they assume the reader will infer the thinking from the artifacts. The reader won’t. Hiring managers don’t have time to do the inference work for you.

The structure that helps

There’s no magic template, but most case studies that work cover the same ground. They tell you what the situation was, what needed to change, what you specifically did (not what the team did), why you chose that approach over the alternatives, and what actually happened.

You don’t need labeled sections for any of this. A short paragraph for each is usually enough. What matters is that all five threads are there.

When I’m reviewing a portfolio and find myself asking “wait, but why did they do that?” I know the case study has lost me. It’s almost always one of those five threads that’s missing.

A small example

Compare these two openings.

“I redesigned the onboarding flow to improve user activation.”

This tells me you did something. It doesn’t tell me what was broken, what you considered, or what you actually learned. I have to trust you completely, and I have no reason to yet.

“Activation was sitting around 18%. The first hypothesis was that users didn’t understand what to do on the empty home screen. But session replays showed they were getting lost on step 3 of the original wizard. So I cut it down to 2 steps and replaced step 3 with an opt-in tutorial. Activation came up to 26%, and we held it for two quarters.”

Same project, different story. The second version doesn’t try to be more impressive. It just makes the thinking visible. The reader can follow the decision chain.

You don’t always need a hard number at the end. “Held for two quarters” matters. “Team aligned around a clearer model” matters, if you’re honest about what you mean. What kills credibility is hiding behind generality.

Things I keep seeing that quietly kill case studies

A few patterns I’d push back on if I were reviewing your portfolio:

Hiding your contribution behind “we.” Team work is normal. But hiring managers want to know what you specifically shaped. If your case study has more “we” than “I,” highlight every “we” and ask whether a stranger would know which decisions were yours. If not, rewrite.

Inflating outcomes you can’t defend. “Improved user experience” is meaningless. “Increased conversion 40%” without context invites the question “compared to what?” If you have hard numbers, ground them. If you don’t, describe the qualitative shift honestly. An honest qualitative description is more credible than a number you can’t defend.

Showing every step equally. Most case studies treat all phases as equally important. They aren’t. The two or three decisions that actually shaped the outcome deserve four times the space of the routine work. Edit ruthlessly.

Hiding constraints. Designers, especially earlier in their careers, often hide constraints because they think the constraints sound like excuses. They don’t. Constraints are part of how real work happens. Hiding them flattens your story.

Worth a try

If you’re stuck, take your most recent case study and read it aloud to someone outside design. Watch where they ask questions. Those gaps are where your reasoning isn’t on the page.

That’s usually faster than any rewrite framework. The questions tell you exactly which thread is missing.

If structured thinking through these threads would help, that’s part of what I’m building Folioverse for. There’s a free template at uxcase.app if you want to try it on your own work first.