Learn how to identify, categorize, and engage stakeholders so your design thinking project earns buy-in and avoids surprises. Includes a power/interest grid, worked examples, and engagement strategies by quadrant.
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.
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 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.
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.
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.
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.
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.
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:
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:
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:
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.
The project lead sits down with a blank spreadsheet and lists every person or role that might be affected:
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.
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.
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.
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.
Related guides: user research on a budget · competitive analysis design thinking · empathy mapping
Design Thinker Labs Home · All Guides · How It Works · Pricing