The short answer
User need is a legitimate and important argument for design decisions. It is also an argument that lands differently depending on who receives it. With stakeholders whose primary concerns are delivery risk, build complexity, or cost, a recommendation framed around user need alone asks them to prioritise something outside their primary frame of reference. The same recommendation, translated into terms that connect to what they are actually managing, is more likely to produce action. Translation is not a compromise as the recommendation does not change. What changes is the language through which it reaches the person who needs to act on it.
Why user need arguments have limited reach
The user need argument — this design decision serves users better — is the foundation of UX practice and the most honest framing for most design recommendations. It is also an argument with a limited audience. Practitioners and researchers receive it on its own terms. Stakeholders with other priorities often don’t.
This is not because those stakeholders don’t care about users. Most do, in principle. The problem is that user need is not a category that appears in their accountability structure. A product director is accountable for delivery outcomes. A technology lead is accountable for build quality and maintainability. A finance stakeholder is accountable for cost and return. User need is relevant to each of them — but it is relevant as a component of what they are accountable for, not as a freestanding priority.
Framing a recommendation in terms of user need asks those stakeholders to translate it themselves into implications for what they actually care about. Some will do that translation, but many will not. This is not out of indifference, but because they are processing many things simultaneously and a recommendation that requires translation is a recommendation that can be deferred.
Translating UX into stakeholder terms
For product directors: delivery risk and outcome quality
Product directors are accountable for what gets built and whether it achieves its intended outcomes. The translation that connects with them is risk: what specific delivery risk does this design decision mitigate? What service failure does it prevent? What post-launch rework does it avoid?
A recommendation framed as ‘this interaction pattern supports user confidence at a critical commitment point’ becomes ‘services that don’t handle this transition clearly typically generate elevated support contact post-launch and often require a design fix in the first release cycle.’ Same recommendation. Different frame. Different likelihood of action.
For technology leads: build complexity and maintainability
Technology leads are accountable for how the service is built and how maintainable it is over time. The translation that connects with them is complexity: what does this design decision make easier or harder to implement? What ambiguities in the current design will require developer judgement calls, and what are those calls likely to produce?
A recommendation framed as ‘this state needs to be communicated explicitly to the user’ becomes ‘if this state isn’t surfaced at this point, developers will need to handle the resulting user behaviour — repeated submissions, support contacts, session returns — as operational exceptions rather than designed interactions. That adds complexity to the implementation and uncertainty to the support model.’
For finance stakeholders: cost and return
Finance stakeholders are accountable for cost efficiency and return on investment. The translation that connects with them is cost: what specific cost does this design decision avoid? What return does it protect?
This translation is most effective when grounded in precedent rather than projection. ‘Research-informed design decisions in comparable services have been associated with lower post-launch rework costs’ is more persuasive than ‘good design will save money’ — it is specific, it is evidenced, and it is expressed in a category the finance stakeholder actually tracks.
Maintaining the user argument
Translating recommendations into stakeholder terms is not a replacement for the user need argument, it is a complement to it. The user need argument remains the foundation: the reason the recommendation exists is that it serves users better. The translation is the bridge: it connects that foundation to the accountability structures of the people who need to act on it.
Practitioners who are effective at this translation typically make both arguments in sequence: here is what this recommendation does for users, and here is why that matters in terms of the outcomes you are accountable for. The first argument establishes the ‘what.’ The second argument establishes the ‘why it matters to you.’ Together, they are more persuasive than either alone.
Instead of asking how to persuade stakeholders to care about UX, ask what they already care about and find the honest intersection between their priorities and your recommendation.
Frequently asked questions
How do you explain UX value to non-design stakeholders?
Explain UX value by connecting it to consequences the stakeholder is already accountable for — delivery risk, build complexity, support costs, or return on investment. The user need argument is the foundation but it needs a bridge to reach people with other priorities. That bridge is the translation: here is what this recommendation means in terms of the outcomes you are responsible for. The recommendation does not change; the framing connects it to what the listener is already managing.
How do you talk about UX to a product director?
Frame UX recommendations in terms of delivery risk and outcome quality. A product director cares about what gets built and whether it works. Connect your recommendation to specific delivery risks it mitigates — post-launch rework, support volume, late-stage design changes — rather than to general UX quality. Be specific about the failure mode the recommendation prevents and be approximate about the cost of that failure based on precedent.
How do you communicate design decisions to a technology team?
Frame design decisions in terms of their build implications: what the design makes clearer or more ambiguous for implementation, which interactions will require developer judgment calls if they’re not designed explicitly, and what the consequences of those judgment calls are likely to be. Technology leads respond to specificity about complexity. A design recommendation that also explains why it reduces implementation uncertainty is more likely to be supported than one presented purely in terms of user experience.
Should you stop using user need arguments with stakeholders?
No. The user need argument is the honest foundation of most design recommendations and should be maintained. What changes is that it should be accompanied by a translation into the accountability terms of the person receiving it. ‘This recommendation serves users better’ is necessary. ‘And here is why that matters to the delivery outcomes you are accountable for’ is what makes it actionable for a stakeholder who has other priorities.