How to Explain Your Design Decisions in a UX Case Study

The real problem

Design decisions are the backbone of a strong UX case study. Screens show what changed, but decisions explain why it changed. Hiring teams are rarely looking for a perfect process. They want to understand how you approached ambiguity, what signals shaped your choices, and how you balanced user needs, business goals, and constraints.

This is exactly where decisions go missing. The designer made a choice for a reason: a constraint, a signal from research, a failed earlier direction. That reasoning stays in the designer’s head. What lands on the portfolio page is just the choice itself. Without the reasoning, the reader has no way to assess the quality of the thinking.

What to focus on instead

The goal when explaining a design decision is not to justify every pixel. Pick the two or three choices that actually changed the direction of the project, and explain what made each one non-obvious. If a decision was simple and obvious, it does not need explanation. If it involved a trade-off, a constraint, or a moment where you could have gone a different way, that is the one to write about.

Key principles:

• Start with the moment where a choice had to be made.
• Explain what options were considered.
• Describe the evidence, constraint, or trade-off behind the decision.
• Connect the decision to the user problem or business goal.
• Avoid saying “we decided” without explaining why.

A practical structure

Use this simple flow:

1. Context: What was the product, and what constraints did you inherit?
2. Problem: What specifically needed to change, and for whom?
3. Role: What were you personally responsible for?
4. Decision: What choices did you make that shaped the direction of the work?
5. Reasoning: What made each choice non-obvious: the constraint, the evidence, the trade-off?
6. Outcome: What changed because of those decisions?

What matters here is not filling all six slots. What matters is that by the time the reader reaches Outcome, they can trace backwards through Reasoning and Decision to understand why the work went the direction it did. If that trace is possible, the decisions are explained.

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 explains a decision. It tells you what the constraint was, what evidence shaped the direction, and what the trade-off looked like. The weak version is just a statement of what happened. No decision visible.

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 case study that explains decisions is readable in a different way. The reader can disagree with your choices, respect your reasoning, and understand your judgment, all from the same page. That is what a decision explanation creates.

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