How to Justify Design Decisions in a UX Case Study

A good UX case study does not only show what you designed.

It explains why the design makes sense.

Hiring teams want to understand your reasoning. They want to see how you moved from problem to decision.

What counts as a design decision?

A design decision can be about:

• Information architecture
• User flow
• Form structure
• Button placement
• Navigation
• Empty states
• Error messages
• Visual hierarchy
• Interaction patterns
• Accessibility choices

Small decisions can reveal strong thinking when they are explained well.

Weak explanation

“We placed the CTA at the bottom because it looked better.”

This does not explain the reasoning. It only describes a preference.

Stronger explanation

“We placed the CTA after the pricing summary because users needed to understand the total cost before committing. This reduced uncertainty at the decision point.”

This explanation is stronger because it connects the decision to user behavior.

Use the decision triangle

For each important decision, connect three things:

1. User need
2. Business goal
3. Constraint

A strong design decision usually balances all three.

For example:

• User need: understand the total cost
• Business goal: increase checkout completion
• Constraint: limited space on mobile
• Decision: show a compact pricing summary before the CTA

Now the design choice is not just visual. It is strategic.

Questions to ask yourself

When writing a case study, ask:

• What problem was this decision solving?
• What alternatives did we consider?
• What user behavior informed it?
• What constraint shaped it?
• What trade-off did we accept?
• How did we know it was better?

You do not need to answer all of these for every detail.

But your most important design decisions should have a clear reason.

Show before and after

If possible, show the earlier version and explain what changed.

Do not just say “we improved the flow.”

Explain what was unclear before and why the new version worked better.

Avoid fake certainty

Not every decision has perfect data behind it.

It is okay to say:

• “Based on usability testing…”
• “Given the technical constraint…”
• “To reduce cognitive load…”
• “Because the team needed a simpler MVP version…”

Honest reasoning is better than overclaiming.

Final thought

Screens show the result.

Design decisions show the designer.

Related guides

• You may also want to writing a case study without metrics: read the guide
• You may also want to showing your contribution in a team project: read the guide