Every design project lives or dies by the people around it. Not just the users you are designing for, but the executives who fund the work, the engineers who build it, the support team who will field complaints, the regulators who might block the whole thing, and the quiet mid-level manager who controls the deployment pipeline and has more practical power than anyone on the org chart above them. Stakeholder mapping is how you figure out who these people are, what they care about, and how to keep them aligned throughout the process.

Skip this step and you will spend weeks on a solution that gets killed in a review meeting by someone you never talked to. Do it well and you will have allies pulling for your project at every stage.

Why Stakeholder Mapping Matters in Design Thinking

Design thinking puts users at the center. That is correct. But "user centered" does not mean "user only." A hospital app that patients love but nurses cannot integrate into their workflow will fail. A checkout flow that converts beautifully but violates PCI compliance will get pulled. A redesigned onboarding process that delights new customers but doubles the workload for the customer success team will be quietly rolled back within a month.

Stakeholder mapping forces you to zoom out and see the full system of people who influence whether your design ever reaches users at all. It answers three questions that empathy research alone cannot: Who has the power to stop this? Who has knowledge we need? And whose daily work will change because of what we build?

The Initialize stage is where this work belongs. Before you do a single interview, before you sketch a single wireframe, you need a clear picture of the human landscape around your project.

The Power/Interest Grid

The Power/Interest stakeholder grid

The most practical stakeholder framework is the power/interest matrix. Draw a 2x2 grid. The vertical axis is power (how much can this person block or accelerate your project?). The horizontal axis is interest (how much do they care about the outcome?). Plot every stakeholder on this grid, and the quadrant they land in tells you how to engage them.

High Power, High Interest: Manage Closely

These are your key players. They can kill your project and they care enough to be watching. Include them in design reviews. Share research findings proactively. Never surprise them with a direction change they learn about secondhand. If they disagree with your approach, you need to know immediately, not three weeks from now in a steering committee meeting.

Engagement cadence: Weekly or biweekly check-ins, depending on project pace. Invite them to key milestone reviews (end of empathy research, problem definition, first prototype). Share drafts before they are finalized so they have a chance to influence direction, not just react to decisions.

Common examples: The VP or director who owns the budget. The product lead who will prioritize engineering resources. The department head whose team's workflow will change. In healthcare, the chief medical officer who must approve any patient-facing change.

High Power, Low Interest: Keep Satisfied

These people can kill your project but probably will not pay attention unless something goes wrong. Your job is to make sure nothing goes wrong from their perspective. Send concise updates at major milestones. Frame updates in terms they care about (business metrics, risk mitigation, compliance status), not design details.

Engagement cadence: Monthly summary emails or brief Slack updates. A 15-minute briefing before any steering committee meeting where your project might come up. If they ask questions, respond immediately; their attention is rare and valuable.

Common examples: Legal counsel (cares about compliance, not UX). The CTO who has 40 other projects to track. Finance leadership who approved the budget six months ago and moved on. The CISO who needs to know about data flow changes but does not care about color palettes.

The danger: Neglecting this quadrant is the most common stakeholder management failure. These people do not bother you, so you forget about them. Then your project hits their radar because of a risk flag, and they shut it down because they feel blindsided. A proactive monthly email costs you 10 minutes and prevents weeks of rework.

Low Power, High Interest: Keep Informed

These people care deeply about the outcome but cannot make or break decisions. They are often your most valuable allies because they live closest to the problem. Customer support reps who hear complaints daily. Junior designers on adjacent teams who understand the product deeply. Subject matter experts who have no authority but have irreplaceable knowledge.

Engagement cadence: Regular updates through a shared channel (Slack, email digest, project wiki). Invite them to research sessions and ideation workshops. Their input during empathy research is often more valuable than their input during design reviews.

The opportunity: People in this quadrant can become your champions. A support lead who feels heard and included will advocate for your project in meetings you are not invited to. An engineer on an adjacent team who understands your goals will flag technical dependencies before they become blockers.

Low Power, Low Interest: Monitor

A quick update email every few weeks is enough. These stakeholders have no direct dependency on your project and cannot influence its outcome. Do not waste time on elaborate engagement plans. But keep them on the radar because quadrant assignments change. A reorg, a new initiative, or a CEO mention can move someone from "Monitor" to "Manage Closely" overnight.

How to Identify Stakeholders (Especially the Non-Obvious Ones)

The obvious stakeholders are easy: your boss, the project sponsor, the engineering lead. The ones who cause problems are the ones you did not think of. Here is a systematic approach that surfaces the hidden stakeholders who blindside projects:

Walk the value chain. Trace your product or service from creation to delivery to support to renewal. Everyone who touches it along the way is a stakeholder. For a SaaS product, that includes: sales (who sets expectations), onboarding (who delivers the first experience), customer success (who manages the relationship), billing (who handles payment issues), support (who fixes problems), and the product team itself.
Ask "who gets upset?" If your design changes a workflow, who has to retrain? If it shifts revenue attribution, whose bonus is affected? If it changes the brand voice, who signed off on the current one? If it adds a new data collection step, who has to update the privacy policy? The people who might be negatively affected are always stakeholders, even if they are not in your department.
Check the org chart sideways. Your project probably has dependencies on adjacent teams you have not considered. The data team that maintains the API you will query. The marketing team that needs to update landing pages if you change the product. The compliance team that needs to review new data flows. The infrastructure team that needs to support any new services you deploy.
Look outside the company. Regulators, partners, vendors, and even competitors can be stakeholders. If you are designing a payments feature, your payment processor is absolutely a stakeholder. If you are in healthcare, the insurance companies that reimburse for your product are stakeholders. If you serve a regulated industry, the regulator is a stakeholder whether you engage them or not.
Ask each stakeholder: "Who else should I talk to?" This is the most reliable way to find hidden stakeholders. Every person you interview knows someone you have not thought of. Follow the chain until you stop hearing new names.

Running Stakeholder Interviews

Once you have your list, talk to the high-power people before you talk to users. This feels backwards but it saves enormous pain later. A 30-minute conversation with each key stakeholder reveals:

What "success" means to them (it is often different from what it means to you or the project sponsor)
What constraints they know about that you do not (technical debt, policy changes, competing initiatives)
What previous attempts have been made and why they failed (organizational memory prevents you from repeating mistakes)
What political dynamics you should be aware of (who is allied with whom, what initiatives compete for the same resources)

Use open questions. "What would make this project a win for you?" is better than "Do you support this project?" The first question reveals their actual priorities. The second just gets you a polite yes that means nothing. Other high-value questions:

"What is the biggest risk you see in this project?" (Reveals concerns they might not volunteer.)
"If this project succeeds, how does it affect your team's work?" (Reveals downstream impacts you might not have considered.)
"What would make you want to block this?" (Confrontational but clarifying. Most people will tell you their dealbreakers when asked directly.)
"Who else should I talk to before we go further?" (Expands your map.)

Worked Example: Redesigning B2B SaaS Onboarding

A mid-size B2B SaaS company with 50 employees decides to redesign its customer onboarding flow. Here is how a stakeholder mapping exercise plays out in practice.

Step 1: Initial Brainstorm (15 minutes)

The project lead sits down with a blank spreadsheet and lists every person or role that might be affected:

VP of Product (owns the product roadmap)
Head of Engineering (controls sprint capacity)
Head of Customer Success (her team runs onboarding calls today)
CFO (cares about conversion and expansion revenue metrics)
Legal (needs to approve any new data collection in the onboarding flow)
Three onboarding specialists (they know exactly where customers get stuck)
Two support engineers (they fix the problems caused by incomplete onboarding)
Marketing lead (owns the website and might need to update positioning)
Sales team (they set expectations during the sales cycle that onboarding must fulfill)
The API integration partner (customers use their service during onboarding)

Step 2: Plot on the Grid

High power, high interest: VP of Product (owns the roadmap and must prioritize this), Head of Engineering (controls whether engineering time is allocated), Head of Customer Success (her team's daily work changes completely)
High power, low interest: CFO (cares about metrics but will not attend design reviews), Legal (needs to approve data changes but does not care about the UX)
Low power, high interest: Onboarding specialists (they live this problem daily and have deep knowledge), support engineers (they see the downstream failures), sales team (they hear what customers expect)
Low power, low interest: Marketing lead (tangential impact), API integration partner (might need a heads-up if the integration flow changes)

Step 3: Engage by Quadrant

The project lead schedules weekly 30-minute syncs with the VP of Product and Head of Customer Success. She books a single 30-minute briefing with the CFO and Legal at project kickoff, with a follow-up at the prototype stage. She invites the onboarding specialists to participate in empathy research sessions as both observers and subject matter experts. She adds the marketing lead and API partner to a biweekly Slack update channel.

What This Prevented

During the stakeholder interview with the Head of Customer Success, the project lead learned that the CS team was already planning to restructure their onboarding call format. Without the interview, the design team would have designed for the current call structure, which was about to change. The stakeholder interview saved at least two weeks of rework.

The Legal interview surfaced a data residency requirement for European customers that the design team did not know about. The onboarding flow needed to route certain data differently based on customer location. This requirement would have been discovered during development and caused a significant delay. Catching it during stakeholder mapping cost 30 minutes instead of 30 days.

Common Mistakes

Treating it as a one-time activity. People change roles. Priorities shift. A stakeholder who was low-interest in January might become high-interest in March because the CEO mentioned your project area in an all-hands meeting. Revisit your map at every stage transition.
Mapping but not acting. If you identified someone as high-power/high-interest but only send them a monthly email, you have not actually managed the relationship. You have just documented your failure in advance.
Confusing seniority with power. A mid-level engineer who controls the deployment pipeline has more practical power over your project than a director who approved it six months ago and moved on. Map actual power (the ability to block, accelerate, or change your project), not organizational rank.
Ignoring internal users. If your project changes an internal workflow, the employees who use that workflow are stakeholders with the same legitimacy as external customers. Their resistance can torpedo adoption just as effectively as customer rejection.
Avoiding the uncomfortable conversations. The stakeholder you are most nervous about interviewing is usually the most important one to talk to. If you are avoiding someone because you think they will push back, that pushback is going to happen eventually. Better to surface it early when you can adapt than late when you cannot.

Connecting Stakeholder Mapping to the Rest of the Process

Your stakeholder map directly feeds other design thinking activities. The people you identified as "low power, high interest" are often your best sources during the Empathize stage because they interact with users daily and have accumulated observations that formal research would take weeks to replicate. The "high power" stakeholders become your review audience during Prototype and Test; showing them evidence early builds the buy-in you need for implementation.

When you write How Might We questions, consider framing some of them around stakeholder constraints: "How might we reduce onboarding time without increasing support team workload?" That kind of question demonstrates that you understand the full system, not just the user's perspective. It also makes stakeholders feel seen, which builds trust.

During facilitated sessions, invite one representative from each high-interest quadrant. The cross-functional perspective prevents solutions that optimize for one group at the expense of another. And when it comes time to present results, your stakeholder map tells you exactly how to tailor the presentation for each audience: metrics for the CFO, workflow details for the CS lead, risk analysis for Legal.

Keeping the Map Alive

Revisit your stakeholder map at every stage transition. As you move from Define to Ideate, the stakeholder landscape often shifts. New technical constraints surface that make the engineering lead more important. A competitor launches something that makes the CEO suddenly interested. A regulatory change moves Legal from "keep satisfied" to "manage closely."

Keep the map simple. A shared spreadsheet with five columns (Name, Role, Power, Interest, Last Contact Date) is more useful than a fancy diagram that nobody updates. The goal is not a beautiful artifact. The goal is that nobody with the power to block your project is ever surprised by it, and nobody with knowledge you need is ever excluded from contributing.