Stakeholder communication and design explanation
Articulating Design Decisions
Articulating Design Decisions is useful when the communication problem is explaining why a design choice matters to people who do not think like designers.
One-Sentence Answer
Articulating Design Decisions is useful when the communication problem is explaining why a design choice matters to people who do not think like designers.
What The Book Is About
Tom Greever's book is a clear fit for stakeholder communication. Design work often fails not because the design is weak, but because the rationale is not explained in business, user, and product terms that stakeholders can evaluate. The book gives communicationbooks.space a practical bridge between visual work and persuasive workplace explanation.
The site angle is not UX craft alone. It is the broader skill of translating expert judgment for non-expert decision makers.
Who Should Read It
- Designers who face taste-based feedback and need to redirect toward goals.
- Product managers and researchers who explain expert tradeoffs to stakeholders.
- Design leads preparing critique sessions, executive reviews, or client presentations.
- Specialists in any field who need to translate expert reasoning for non-experts.
Main Summary
Articulating Design Decisions is a stakeholder communication book disguised as a design book. Tom Greever's core problem is familiar across expert work: the person doing the work has reasons, constraints, and evidence in mind, while stakeholders see only the final artifact and react through preference, anxiety, or organizational pressure. The communicator's job is to make the rationale visible enough for a useful decision.
For designers, that means explaining how a choice supports user needs, business goals, technical constraints, or product strategy. Without that explanation, a review can collapse into 'I like it' versus 'I do not like it.' With good articulation, the conversation shifts toward whether the decision serves the agreed goal. This is why the book fits communicationbooks.space. It teaches readers how to turn expert judgment into shared evaluation.
The book is especially useful before design reviews and stakeholder meetings. A designer can prepare by naming the problem, the users affected, the options considered, the tradeoff made, and the kind of feedback needed now. It also helps with objections. Instead of defending every pixel, the communicator can ask what risk the stakeholder sees and connect the answer back to the decision criteria. The skill applies beyond UX: analysts, engineers, strategists, and consultants all need to articulate decisions without making disagreement personal.
A final reading should emphasize that articulation is part of the design work, not a cosmetic afterthought. A design decision that cannot be explained through goals, constraints, evidence, and tradeoffs is vulnerable to taste-based reversal. Greever's book helps the communicator prepare the room for better critique: what problem is being solved, which alternative lost, what feedback is useful now, and what risk the stakeholder may be trying to protect. This makes it relevant to many expert roles, not only UX designers.
Key Ideas
1. Rationale must connect to goals
A design choice is easier to support when it is tied to user behavior, business outcomes, constraints, or evidence rather than personal preference.
A design choice should be explained through the problem it solves. If the communicator begins with aesthetics, stakeholders may respond with taste. If the communicator begins with goals, evidence, and constraints, the room has better criteria for discussion.
Why it matters: goal-based rationale shifts feedback away from taste. Apply this by opening a design review with the user problem, product goal, and constraint before showing the solution. The room then has criteria to use.
In a design review, start with the decision criteria: user task, business goal, constraint, and evidence. Then show the design. This order matters because stakeholders evaluate what they are prepared to see. If they see the screen first, they may default to color, taste, or personal preference.
A checkout redesign can be introduced as 'reducing hesitation before payment,' not 'cleaning up the UI.' That framing gives stakeholders a business and user lens. The design then becomes a response to a problem, not an object waiting for taste reactions.
For example, a designer might say, 'This layout reduces comparison steps for returning customers,' before discussing spacing or components.
2. Stakeholders need translation
Decision makers may not share design vocabulary. The communicator must explain the choice in terms the audience can judge.
Stakeholders often speak in the language of preference because they do not have the maker's vocabulary. The designer's responsibility is translation. That may mean converting interaction details into user risk, conversion impact, support burden, accessibility, or brand trust.
Why it matters: translation prevents stakeholders from rejecting what they cannot evaluate. Apply this by converting design terms into user behavior, revenue risk, support cost, accessibility, trust, or implementation tradeoffs.
Translation might turn 'information architecture' into 'customers can find pricing before they abandon the page.' It might turn 'visual hierarchy' into 'the primary action is obvious before the secondary links.' The designer earns trust by connecting craft language to outcomes stakeholders already care about.
Translation can also reduce executive impatience. Instead of explaining every component state, the designer can say which customer confusion each state prevents. Detail remains available, but the review starts at the level where stakeholders make decisions.
This translation is also respectful: it does not ask executives to become designers before they can contribute useful judgment.
A product leader can then challenge the goal or evidence directly, which is a healthier disagreement than arguing over visual preference.
3. Objections are part of the work
A question about a design is not automatically an attack. Preparing for objections keeps the conversation focused on evidence and tradeoffs.
Objections should be expected and prepared for. A stakeholder who questions a decision may be protecting budget, timeline, reputation, customer expectations, or political alignment. Understanding the concern lets the communicator answer the real issue instead of reacting defensively.
Why it matters: objections often contain useful risk signals. Apply this by asking what concern sits behind the objection, then tying the answer back to the decision criteria instead of defending every visual detail.
When a stakeholder objects, ask what risk they are seeing: adoption, brand, legal, speed, support load, or executive preference. A design communicator who can name the risk can respond with evidence or tradeoff. This is more productive than defending the original choice as simply 'best practice.'
If a stakeholder says a design feels too plain, the communicator can ask whether the concern is brand distinctiveness, conversion confidence, or hierarchy. Each answer suggests different evidence. The objection becomes a design question rather than a taste stalemate.
Sometimes the objection reveals missing evidence, such as no usability test for a risky flow. That is a better discovery than a defensive debate.
4. Alternatives show judgment
Explaining what was considered and rejected can make the final choice more credible. It shows that the decision was not arbitrary.
Showing alternatives can strengthen trust because it reveals judgment. The audience sees that the final choice was selected from options, not produced by instinct alone. Alternatives also make tradeoffs explicit: speed versus clarity, novelty versus familiarity, density versus ease.
Why it matters: alternatives show that the recommendation is a choice, not a preference. Apply this by bringing one rejected option and naming why it lost: confusion, cost, inconsistency, risk, or weaker user fit.
Alternatives make rationale visible. Bring a version that maximizes speed, one that maximizes clarity, and one that balances both. Explain why the chosen option won. Stakeholders may still disagree, but the conversation moves from taste to tradeoff.
A rejected alternative might be faster to build but weaker for accessibility. Another might be visually striking but less familiar to returning users. Showing these tradeoffs helps stakeholders see that the chosen design is not the only possible design, but the best fit for the criteria.
Alternatives also help when stakeholders ask why a familiar pattern changed; the designer can show what the familiar pattern failed to solve.
This also shows respect for stakeholder constraints; sometimes the concern is real, but it was expressed as taste.
5. Critique needs structure
Without structure, feedback becomes scattered taste. A clear frame helps stakeholders respond to the right level of the work.
Why it matters: unframed critique becomes scattered. Apply this by telling stakeholders what kind of feedback is useful now: strategy, flow, content, visual hierarchy, usability, or feasibility. The frame makes critique more actionable.
A good review has a feedback frame. The communicator should say whether they need input on strategy, flow, content, visual direction, usability risk, or implementation detail. Otherwise stakeholders may critique whatever is easiest to notice.
A critique frame can sound like: 'Today I need feedback on the flow, not visual polish.' Or: 'The visual style is set; I need to test whether the empty state explains recovery.' This protects the review from scattered comments and gives stakeholders a useful role.
Critique framing is especially important in remote reviews where comments can scatter across a file. A designer can ask reviewers to tag feedback as user-flow, content, visual, or feasibility. That makes synthesis easier and keeps one loud preference from dominating.
The frame should be repeated when feedback drifts, because review rooms naturally return to whatever is easiest to notice.
The communicator can close by restating which feedback will change the decision and which feedback belongs to a later layer.
Practical Takeaways
- Explain the user or business problem before showing the design choice.
- Name the tradeoff the decision makes.
- Prepare the likely stakeholder objection before the review.
- Translate design language into outcomes the audience cares about.
- Show alternatives when a decision may look subjective.
- Ask for feedback on the decision criteria, not only visual preference.
How To Apply It
Before a stakeholder review, write three bullets for each major decision: goal served, evidence or constraint, and tradeoff. Open with those bullets before asking for critique.
A deeper application is to prepare a design-review brief before the meeting. For each major choice, write the user problem, the business or product goal, the rejected alternative, the tradeoff, and the feedback needed. During the review, open with those criteria so stakeholders know how to evaluate the work. If someone says, 'I don't like this,' translate the comment into a testable concern: is the issue clarity, trust, conversion, accessibility, brand fit, or implementation cost? That move keeps the conversation from becoming personal. The book is strongest for professionals whose work is judged by people who do not share their craft vocabulary.
Original Value: When This Book Is Most Useful
Read this book when the artifact is not speaking for itself and stakeholder trust matters. It is not primarily a visual-design manual. Its best value is helping experts explain why a decision is reasonable, what tradeoff it makes, and what feedback would improve it. That makes it relevant for any professional who must defend work without becoming defensive.
Do not treat articulation as a way to overpower stakeholders with jargon. The point is shared understanding, not winning a vocabulary contest. If stakeholders keep objecting, the communicator should ask whether the criteria are wrong, the evidence is weak, or the concern is organizational rather than visual. That humility keeps rationale from becoming defensiveness.
Best Related Books
- The Art of Explanation
- The Pyramid Principle
- Good Charts
- The Back of the Napkin
Internal Links
- /books/the-art-of-explanation/
- /books/the-pyramid-principle/
- /books/good-charts/
- /books/the-back-of-the-napkin/