How to Turn a Simple UX Project Into a Strong Case Study

The real problem

Many designers avoid writing about smaller projects because they think the work is not impressive enough. But a strong case study does not always come from a big product launch. It can come from a clear problem, a thoughtful decision, a real constraint, and a useful learning.

This problem is more common on smaller projects, where designers feel pressure to compensate by adding context that makes the work seem more significant. The additions often work against the case study. Extra screens, vague impact claims, and padded process descriptions make a simple project feel thin rather than focused.

What to focus on instead

A simple project becomes a strong case study when you stop trying to make it sound like more than it was, and start showing the specificity of the thinking inside it. The constraint that shaped the solution. The one decision that was not obvious. The thing you would approach differently today.

Key principles:

• Focus on the decision quality, not project size.
• Show what made the problem specific.
• Explain one constraint that shaped the solution.
• Make your personal role visible.
• End with what you learned or would improve.

A practical structure

Use this simple flow:

1. Context: What was the product or situation, even if it was small-scale?
2. Problem: What was the specific thing that needed to change?
3. Role: What were you responsible for, and what did you actually do?
4. Decision: What were the one or two choices that shaped the solution?
5. Reasoning: What constraint, evidence, or trade-off made those choices non-obvious?
6. Outcome: What changed, what held, or what did you learn?

For a smaller project, you may only have one or two items to write in each row, and that is enough. A case study that covers three focused points well is stronger than one that covers six points vaguely.

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 works for a small project because it describes something specific. A reviewer reading it knows exactly what the problem was and what changed. That specificity is what makes a simple project credible. Scale is beside the point.

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

A simple project does not need to be a big project to be a credible one. It needs to show that you understood the problem, made a decision you can explain, and know what the work produced. The scale of the project matters less than the clarity of the thinking.

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