Stakeholder Management for Designers: Power, Interest, and Attitude
Managing stakeholders means deciding how much and how to involve those who influence a project. How to map power, interest, and attitude and pick a strategy.
What does managing stakeholders mean?
A stakeholder is anyone who affects or is affected by the project. In a redesign it can be the sales director, the legal team, the support lead, or a developer who maintains the codebase. Ignoring one of them usually costs a lot in the final week.
Managing doesn’t mean treating everyone the same. It means spending more time on the people who can stall or accelerate the project, and less on those who only need to know what is happening.
How do you map them?
The classic tool is the power and interest matrix, known as Mendelow’s matrix after Aubrey Mendelow. It places each stakeholder on two axes: how much power they have to influence or block the project, and how much interest they have in the outcome. NN/g adds a third axis, attitude: whether the person is supportive, neutral, or opposed to the design work (NN/g, “Stakeholder analysis for UX projects”).
That third axis matters because two people with the same power can act in opposite ways. One supports you and another blocks you. The map has to capture both.
Which strategy fits each quadrant?
NN/g proposes four strategies, one per quadrant:
- High power, high interest: manage closely. They can block the project or become champions. Involve them in decisions, ask for their judgment, and review every major delivery with them.
- High power, low interest: keep satisfied. These are the latent stakeholders. Make sure their interests are met and consult them when your work affects theirs, so they don’t appear at the end with an objection.
- Low power, high interest: keep informed. Invite them to research sessions, copy them on debrief emails, and invite them to design critiques. They are often useful allies.
- Low power, low interest: monitor. Don’t spend much effort, but check on them regularly in case their power or interest changes.
NN/g warns that these strategies are not specific: the best one depends on the person and on the organization’s culture.
How do you get to know a stakeholder?
Interviews are the most useful tool. UserTesting collects advice from several practitioners: ask about the ideal outcomes of the research, what happened the last time research was done, what they know about their users, and what their ideal timeline and approach would be (UserTesting, “How to get stakeholder buy-in for user research”).
NN/g adds that interviews can reveal how much the person knows about UX. If someone with a lot of power knows little, it’s worth spending time on the basics and on the return of design work before asking for a decision.
How do you build support?
Baymard, in a guide on presenting findings, proposes several practices: explain the methodology at the start, use external evidence so you don’t depend on internal opinions, translate findings into business metrics such as conversion, customer lifetime value, or call-center volume, and close with clear next steps: priority, business consequence, effort, timeline, and the permissions you need before signing off (Baymard, “How to present UX research findings to get buy-in”). That guide comes from a company that sells UX research, so read it as practice, not as evidence.
The underlying rule is trust. One practitioner quoted by UserTesting recommends settling the stakeholder’s urgent doubts first and leaving broader topics for when credibility exists. Involving them in workshops and research sessions also helps: whoever takes part feels the project belongs to them.
Example
Illustrative example: a designer is going to redesign the returns process of an online store. Their map has five people. The operations director has high power and high interest, but is skeptical: she thinks the problem is the carriers. She is managed closely through an interview where the designer asks which metrics she uses to decide, and then they review two recorded returns together with her team. The legal lead has high power and low interest: he is consulted only about the wording of the returns policy. The support team, with low power and high interest, is invited to the sessions and to review the prototype. Three weeks later the map changes: the director has moved from skeptic to ally.
When NOT to involve everyone
- When the decision is small. A color change doesn’t need the leadership team’s participation.
- When participation turns into a committee. Too many approvers stall the work. Define who decides.
- When the person has nothing to contribute. Involving someone just to tick a box creates noise and resentment.
- When the conflict is about power, not information. Then escalate to whoever holds the authority instead of explaining again.
Common mistakes
- Mapping once and never reviewing the map.
- Treating attitude as fixed.
- Talking only to the person with the most power and forgetting who uses the product.
- Presenting critical findings without context, which can trigger rejection.
- Confusing stakeholder management with pleasing everyone.
How to start tomorrow
Before your next project meeting, list the people who affect the outcome. For each one, write their power, interest, and attitude in one sentence. Assign a quadrant and a strategy. Pick one person with high power and low interest and ask for a twenty-minute interview about their goals. Then update the map. If the project needs to justify its return, that conversation is a good moment to agree on how it will be measured. For that, see ROI of UX. And to close the process, a project kickoff is the place to assign owners.