Stakeholder relationship management is one of the most important yet often overlooked skills in UX.
Modern UX Design courses typically focus on topics such as design frameworks, research methods, interaction design, prototyping, and usability. Those are all important. But once you start working on real products, you quickly realize that success depends on how well you work with people. Good ideas rarely make it into products on their own. They need the support and buy-in of other people, who in turn need your influence and persuasion.
Why AI Makes This More Relevant
For many aspects of UX work, AI can make you go faster. Early design ideas can be produced with a few prompts. Anyone can generate complex prototypes in minutes.
Great. But what do you do with all those prototypes? Eventually you need to share your design proposals. AI can’t build trust between teams. And it can’t persuade a diverse group of stakeholders to support a particular direction.
As design work and technical work become easier to automate, the value of UX design is shifting. The role is becoming less about generating design artifacts and more about guiding design decisions. Soft skills like active listening, storytelling, negotiation, and diplomacy are more important than ever.
What Is a Stakeholder Anyway?
A stakeholder is anyone who is affected by the outcome of your work, has influence over the project, or has a significant interest in it.
This includes people you collaborate with every day, as well as people who appear only at key moments in the product development lifecycle.
Of course, not all stakeholders show up the same way. Some will shape the direction. Some are hands-on in the daily work. Some approve decisions. Some simply have to live with the outcome.
All of them matter, but they do not all play the same role or carry the same weight for your project.
Start With Your Core Alignment Group
Before sharing work widely, start by aligning closely with the people most directly involved in delivering the product.
For a UX designer, this usually begins with the Product Manager. In many teams the PM becomes the designer’s main sparring partner. Rough sketches, draft designs, and early prototypes can be explored quickly together, going back and forth with feedback and quick iterations until you are both confident about the direction.
The engineering lead is often part of this small group too. In most cases this inner group is just two or three people.
Beyond that sits a slightly wider working group. This might include the other engineers working on the feature or product, and perhaps a few others closely involved in delivery, such as a program manager, architect, or subject matter expert.
The exact structure varies from team to team and from project to project. But the principle is the same: before opening design discussions further, make sure this small group is broadly on the same page.
When this core group is aligned early, wider conversations tend to go much more smoothly.
Not every stakeholder needs the same level of attention. Part of stakeholder management is recognizing who needs deep involvement, who needs to be consulted along the way, and who just needs to be kept informed.
With any group, it helps to be clear about the intent. In some cases you are asking for input. In others, you are simply sharing context and decisions that have already been made.
Focus most of your attention on the people who influence the outcome.
Agree on the Problem
Ask a few simple questions early in the project and ensure stakeholders agree on the answers, as far as possible:
- What problem are we solving?
- What does success look like?
- How will we measure it?
Different stakeholders often have different assumptions about these things.
If those assumptions are not clarified early, feedback on design work can quickly become confusing or contradictory. When everyone agrees on the problem and the goal, design discussions become much easier.
Control the Flow of Feedback
Feedback can quickly become overwhelming if it arrives from too many directions at once.
One useful way to manage this is to think about feedback like a faucet. Don’t turn it on full blast immediately. Open it gradually.
Start with the smallest group: the inner circle described earlier, closest to the work. This is where early ideas are explored and tested. At first the designs may be rough, and even the requirements may still be taking shape. The goal at this stage is to start converging on a promising direction.
Once the direction becomes clearer, widen the circle slightly. This might include adjacent teams, subject matter experts, or managers involved in the project. The work is still open to change, but the adjustments should start to become smaller.
Only when the work is reasonably mature should it be shown to a wider audience or leadership group. By this point, the core stakeholders should already be broadly agreed on the direction.
If feedback enters too early from too many directions, discussions can quickly become messy. People react in real time, explore new ideas on the spot, and suddenly the group is debating multiple directions at once.
Opening the faucet gradually keeps feedback focused, allows alignment to build step by step as the circle widens, and avoids lurching from one design direction to another with each review.
At each step, level-set your audience before presenting any designs. Briefly recap the agreed persona, key use case, and the fundamental problem statement. This ensures all reviewers are anchored in the same reality. It also helps to prevent feedback from veering into unrelated topics, and to keep the discussion focused on solving the defined problem for the target user.
Avoid surprising the people you work most closely with. Where possible, share early previews with your PM, engineering lead, or immediate collaborators in one-to-one conversations first, even if it’s just a five-minute chat before a meeting.
“I wanted to get your thoughts on this before I show the others.”
This helps you surface concerns early and prevents big disagreements later.
The Art of Receiving Feedback
As the circle of stakeholders widens, the amount of feedback naturally increases. Much of it will be useful, but some of it will be less relevant. Some people give feedback simply because they were invited and feel they should say something.
A simple response works well in most situations:
"Thank you, noted," or "We'll take that into consideration."
This acknowledges the person and shows that you’ve heard the feedback without forcing you to respond immediately or defend every decision on the spot.
You don’t need to accept every suggestion. Part of the job is interpreting the feedback and deciding what is worth acting on. You can always go back to your inner circle to help make those decisions.
Of course, if the same concern comes up more than once, it probably deserves attention.
Show That You Listened
One of the most common mistakes in stakeholder relationship management is failing to close the loop after a feedback session.
After a review meeting, make sure there is a follow-up. This might be another session with the same group, or simply a short message that summarizes the feedback that was discussed.
This does two things. First, it confirms that the feedback was captured. Second, it gives you a chance to show people that you understood what they were trying to say.
For example, you might summarize it like this:
“We heard three main themes from the last review…”
When people see their feedback reflected back like this, they feel heard. And when people feel heard, they are usually much more comfortable if the final direction ends up being slightly different from what they originally suggested. Even when you don't incorporate a specific suggestion, you must show you considered it and provide a clear rationale for the final trade-off.
Good stakeholder relationship management should feel collaborative. Stakeholders should feel like they are part of shaping something important in the product. If people feel excluded from the process, that can lead to resistance later on. Taking people along on the design journey builds trust and makes decisions easier to land.
Work Through Difficult Feedback
Sooner or later you will encounter feedback that you strongly disagree with.
In those moments, it usually helps to stay open rather than pushing back immediately.
Instead of trying to “win” the argument, one useful approach is to take the stakeholder a little further along the design journey. Try exploring their ideas properly. Build the version they suggested and place it alongside your recommended approach. Then talk them through how you got there.
For example: “We explored your suggestion and mocked up how it might work. As you can see, it created a few problems around X. So we refined it, and this version works better for Y reasons.”
When both options are visible side-by-side, the trade-offs usually become much clearer. And sometimes the stakeholder’s instinct turns out to be right. You won’t know until you try it.
Instead of arguing about ideas in the abstract, let the design work speak for itself.
Why Stakeholder Relationship Management Matters for UX Designers
Stakeholder relationship management is what happens on the journey between a design idea and a feature that ultimately makes it into the product.
It’s not something you learn from a book or a bootcamp. It’s a skill you develop through experience.
The principles are simple: align early, manage feedback carefully, and focus on the people who shape decisions.
Great designs don’t get shipped until you help others believe in them.