A design decision becomes understandable when the reader can compare realistic alternatives against the same need. Explain the constraint, the options considered and the evidence behind your choice. Show the tradeoff and any remaining uncertainty. Avoid inventing weak alternatives merely to make the final design appear inevitable or universally best.
Frame the decision before showing the final screen
Begin with the task the design needed to support and the constraint that shaped it. A screen, document or service flow may need to help someone compare options, recover from an error or complete a handover. State the specific decision you made within that task. “Choosing how to show unresolved requests” gives the reader a clearer question than “improving the user experience.”
Identify what was known at the time. You may have had a brief, existing guidance, stakeholder input or exploratory observations. Distinguish those sources from assumptions. A preference expressed by one stakeholder is not evidence that every user prefers the same option. The case study can explain how limited information shaped a provisional decision without making the process seem more certain than it was.
Compare alternatives fairly
Choose alternatives that could realistically have been used. Explain each using the same criteria, such as clarity, effort, accessibility, maintenance or operational fit. A table may help, but its judgments need short explanations. Avoid assigning precise scores when there was no defensible scoring method; a reasoned comparison can be more honest than a numerical ranking built after the decision.
Show enough of each alternative to reveal the difference. A sketch, small text example or interaction sequence may be sufficient. Do not redesign a rejected option to look worse in retrospect. Explain what it did well and why another concern mattered more in this situation. Good decision-making involves selecting an acceptable tradeoff, not proving that every other approach was foolish.
Connect the choice with evidence and limits
Describe how the decision was made: your recommendation, the review discussion and the person or group with approval authority. If the choice was tested, explain the test’s scope and what was observed. If it was not tested, label the rationale as a reasoned proposal. A polished final artifact does not convert an assumption about behavior into evidence of effectiveness.
Name the cost of the choice. A simpler interface may offer fewer controls; a detailed document may take longer to scan; a manual review step may improve oversight while adding work. Showing the cost helps a reviewer assess whether you understood the system around the artifact. It also gives you a useful answer when asked what you would revisit under different conditions.
End with the next evidence that could change the decision. This might be testing comprehension, reviewing keyboard use or observing how a process behaves during busy periods. Be specific about the uncertainty. A case study that says further testing is needed without identifying the question leaves the reader unable to see how the design could develop responsibly.
Fictional example: showing unresolved requests
A fictional designer is preparing a personal prototype for a volunteer help desk. They compare two ways to display unresolved requests: placing them in a separate tab or keeping them in the main list with a visible status. The tab makes the main view shorter, but may hide outstanding work. The visible status keeps all work together, but increases scanning effort. No live service or real user testing is involved.
The designer chooses the main-list status for the prototype and explains the tradeoff beside the sketches. They include a text status rather than relying only on color. The next check would ask representative reviewers to locate unresolved items and explain what action is expected. The case study labels that check as planned, so the rationale demonstrates considered design judgment without claiming validated usability or adoption.
A checklist for your next step
- Define one decision and its practical constraint.
- Separate evidence from assumptions.
- Compare credible options using the same criteria.
- Explain the chosen tradeoff and approval role.
- Name the next observation that could change the choice.
Common questions
Do I need to show every discarded version?
No. Select alternatives that illuminate the important decision. Repeated cosmetic variations add little unless they explain a meaningful constraint or change in reasoning.
Can I explain a decision without user research?
Yes, by accurately describing the available evidence and your assumptions. Present it as a reasoned choice with limits, rather than claiming that users validated an approach they never evaluated.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AliveCV.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.