Why UX Case Studies Get Rejected (and How to Fix Yours)

If you want to understand why ux case studies get rejected, stop looking at the visuals. In 2026, reviewers spend a few minutes per portfolio and they are reading for one thing: can this person think clearly through a real problem? Most rejected case studies look finished. They just don’t prove that.

Below are the six reasons reviewers move on, each with a red-flag line and the stronger version that fixes it. Every fix comes from a real example case study you can read in full in the UX case study examples.

The shift that matters in 2026: “I followed a perfect process” is no longer impressive on its own. “Here’s how I reasoned through a messy problem, and here’s what I’m honestly unsure about” is. The bar moved from showing work to showing judgment.

1. It shows activities, not decisions

This is the most common reason. A list of activities — interviews, personas, wireframes, usability tests, UI — tells a reviewer what you did, not what you decided.

Red flag:

“I created three personas to understand the users.”

Fix:

“The personas mattered less than the task patterns. Two user groups had different motivations but failed at the same decision point, so I focused on that shared breakdown.”

A reviewer can evaluate the second version. The first is just motion. The fix is always the same: replace the activity with the decision it led to.

2. The role is unclear

If a reviewer can’t tell what you personally did, they assume the least. “We” everywhere is a red flag, especially on a team project.

Red flag:

“We conducted research and designed the solution.”

Fix:

“I led product design on the Freightline operations dashboard, with a PM, three engineers, and a data analyst. I owned research, the exception-first layout, and the severity system; the analyst built the metrics behind it.”

Naming what others owned makes your contribution clearer, not smaller. See the B2B logistics dashboard teardown.

3. The problem is too broad

A problem you can’t design against produces a case you can’t evaluate. Beginners especially reach for problems the size of an industry.

Red flag:

“People need a better way to manage their money.”

Fix:

“Users were dropping off at the transfer confirmation step, and support kept getting ‘I sent money to the wrong person’ tickets. In banking, one scary moment kills confidence.”

The fix narrows the problem until it has a target. The fintech transfer teardown shows how a tight problem statement carries the whole case.

4. The results are inflated or invented

Nothing gets a case dismissed faster than impact a reviewer doesn’t believe. Fabricated metrics, vague “improved engagement,” or claiming business results from a concept all read as red flags.

Red flag:

“This redesign increased user satisfaction and business performance.”

Fix (a concept with no production data):

“This is a concept, so there are no production metrics. I validated direction with a prototype test on six new owners: comprehension was clear and self-rated confidence rose. I’m careful not to claim numbers it doesn’t have.”

Fix (a limited pilot):

“I piloted with one ops team for four weeks. Time to identify an at-risk shipment dropped meaningfully — I frame it as a pilot signal, one team alongside other changes, not a platform-wide result.”

Honest, scoped results read as senior. The 0-to-1 pet-care teardown is built entirely on this kind of honesty.

5. No thinking is visible

A case that shows only the final decision hides the reasoning. Reviewers want to see the alternative you rejected and why.

Red flag:

“I simplified the dashboard layout.”

Fix:

“The core decision wasn’t a screen — it was a system: one shared language for risk applied across the whole product. I considered just restyling the status on this one screen, but it was shown five inconsistent ways everywhere, so a local fix wouldn’t have solved the real problem.”

Showing the alternative is what turns a screenshot into evidence of judgment.

6. The reviewer has to work to understand it

Length without hierarchy is a rejection reason on its own. If the important parts are buried under process labels, a busy reviewer won’t dig for them.

Red flag:

A case study that opens with “Discover, Define, Ideate, Prototype, Test” and 30 screens.

Fix:

Lead with the problem and your role, surface the two or three decisions that mattered, and cut everything that doesn’t carry reasoning. One strong, well-explained project beats many shallow ones.

How to catch these before you submit

Read your own case the way a reviewer will and ask four questions: Can I understand the problem in 30 seconds? Is the role clear? Do I see how you think, not just what you made? Would I trust you with a real product problem?

For the full structure, use the UX case study guide. For a final pass, run the UX case study checklist. And if you’re building a first piece, start with how to write a UX case study with no experience.

The hardest part is that these problems are invisible to the person who wrote the case — you know what you meant, so the gaps don’t show. That’s exactly the gap a second set of eyes catches.