Common UX Case Study Mistakes That Make Strong Work Look Weak

The real problem

A weak case study does not always mean weak work. Often, the work is solid but the story is hard to follow. The most common mistakes happen when designers show outputs without context, describe process without decisions, or claim impact without evidence.

Each of these mistakes follows the same underlying pattern: the designer knows what happened, so they leave the reader to infer it. But a reviewer reading cold has no shared context. They see screens, steps, and claims. They have to decide how much to trust each one. When the reasoning is absent, even strong work reads as ambiguous.

What to focus on instead

Fixing these mistakes does not mean rewriting everything from scratch. Most of the time, the work is already there. It just needs the reasoning made explicit. What changed in the design, why that change made sense, and what happened after are the three threads that most weak case studies are missing.

Key principles:

• Too many screens, not enough context.
• Unclear personal contribution.
• Process listed as steps instead of reasoning.
• No trade-offs or constraints.
• Outcome section that is either missing or exaggerated.

A practical structure

Use this simple flow:

1. Context: Is the product or situation clear to someone who was not there?
2. Problem: Is what needed to change stated directly, not implied?
3. Role: Is your specific contribution named, not hidden in “we”?
4. Decision: Are the choices you made described, or just the outcomes?
5. Reasoning: Is there evidence, a constraint, or a trade-off behind each decision?
6. Outcome: Is the impact specific and honest, or vague and overclaimed?

Running your case study against each of these six points is a fast way to catch the most common mistakes before you share it. If any point has a blank, that is where the story stops for the reader.

Example framing

Weak framing:

I redesigned the flow and improved the user experience.

Stronger framing:

I focused on the onboarding step where users were unsure what to do next. Instead of adding more explanation, I simplified the sequence and made the next action more visible. This helped the team align around a clearer first-use experience.

The stronger version corrects two of the most common mistakes at once: it scopes the claim to something specific, and it shows the reasoning behind the change rather than just the change itself.

What to avoid

• Do not turn the case study into a gallery of screens.
• Do not hide your role behind vague “we” language.
• Do not overclaim impact if you do not have evidence.
• Do not describe every step equally; highlight the decisions that mattered.
• Do not copy another designer’s case study structure without adapting it to your own project.

Final thought

Most case study mistakes are not about the quality of the work. They are about what got left off the page. The work is usually there. The reasoning is what is missing.

More case study guides

• what hiring managers look for in UX case studies
• writing a UX case study without metrics
• showing your contribution in a team project