Another key lesson I took away from Articulating Design Decisions is that effective design communication starts with understanding who you’re talking to and what they care about. As designers, we don’t just present solutions—we translate them in ways that resonate with different stakeholder priorities.

I see this play out regularly in my own work. When I’m designing under real-world constraints, I often check in with developers early to ensure my ideas are technically feasible. These conversations help me understand where flexibility exists and where it doesn’t, allowing me to adjust designs before they become costly to change. Without that alignment, even well-intentioned designs can fall apart during implementation. Similarly, when presenting work to a platform product owner, I’ve learned that it’s not enough to explain how a design works. I need to clearly articulate how it drives engagement, supports scalability, or improves consistency across the platform. The same design can be perceived very differently depending on whether it’s framed as a usability improvement, a performance gain, or a long-term system investment.

The book helped me put language to something I’ve experienced firsthand: stakeholders aren’t pushing back on design because they don’t value UX —they’re evaluating it through the lens of their own responsibilities. Developers are optimizing for feasibility and efficiency. Product owners are balancing engagement, adoption, and roadmap priorities. Executives are thinking about outcomes and impact. Each perspective is valid, but incomplete on its own.

The book reinforced something I’ve experienced repeatedly: most design conflict isn’t a design problem—it’s a communication problem. Every stakeholder is optimizing for something different. Design decisions only land when they’re framed in a way that speaks directly to those motivations. When that framing is missing, even strong solutions can be questioned, diluted, or abandoned entirely.

What’s changed for me is being more intentional about framing design outcomes in ways that directly address these viewpoints. When designers anticipate stakeholder concerns and speak to them clearly, conversations become more focused, trust builds faster, and alignment happens earlier in the process.

To support this mindset—both for readers and for my future self—I took time to create the stakeholder breakdown below as a reference. It’s a reminder to pause, consider who I’m designing and presenting for, and intentionally align my communication with what matters most to them.

Stakeholder Reference: Prespectives & Priorities

Stakeholder Type Perspectives & Priorities
Users / Customers Care about clarity, ease of use, efficiency, and trust. Evaluate success based on whether the product helps them accomplish their goals with minimal friction.
Product Managers / Product Owners Balance user needs, business objectives, timelines, and scope. Focus on prioritization, impact, and roadmap alignment.
Developers / Engineers Optimize for technical feasibility, performance, maintainability, and delivery effort.
Marketing Focus on messaging, brand consistency, and how the product is perceived across touchpoints.
Executives / Leadership Evaluate design through outcomes such as revenue, growth, risk reduction, and strategic alignment.
Sales / Client-Facing Teams Value designs that are easy to explain, demo, and position competitively.
Customer Support / Customer Success Experience the downstream effects of design decisions through user confusion, support tickets, and adoption challenges.
Legal, Compliance, & Accessiibility Teams Focus on risk mitigation, regulatory requirements, and ensuring products meet accessibility standards.