Design systems are never just about components, tokens, and Figma libraries. They’re about people with competing priorities, different goals, and varying levels of design system literacy.
If you’ve worked on a design system, you already know: getting the system right is only half the job. Getting stakeholders on board is the other half.
In my work leading design systems, I’ve learned (sometimes the hard way) that stakeholder management isn’t a side task, but it is the task. Here’s what’s actually worked in practice.
1. Involve the Right People—From Day One
A common trap: design systems get built in a vacuum, then unveiled with fanfare, only to be met with confusion or resistance. Why? Because the teams it was meant to help weren’t involved early.
Tip: Map out every group the system touches and they coould be designers, engineers, PMs, accessibility specialists, QA, brand, leadership and bring them in early. Not all at once, but deliberately, based on what stage you’re in. Start with listening and ask:
- What’s frustrating about the current workflow?
- Where are the inconsistencies causing real problems?
- What would a “successful” design system look like to you?
This isn’t about gathering a wishlist—it’s about understanding pain points so you can solve real problems, not imagined ones.
2. Co-create, Don’t Just “Roll Out”
Design systems that succeed feel co-owned by the teams who use them.
I’ve seen the difference between launching something for teams vs. with them. When teams help shape components, influence documentation, or pilot new features, they’re more likely to use the system and advocate for it.
Ways to make this happen:
- Invite feedback early in the component lifecycle (not just after it’s built).
- Run async design critiques or open RFCs for system changes.
- Use pilot teams as partners not test subjects.
Yes, this takes more time. But it saves you from pushing a system no one asked for.
3. Be Clear About Roles (Or Risk Chaos)
In any design system work, ambiguity is the enemy. Especially when it comes to decision-making. Who gets a vote? Who gets a veto? Who’s just being kept informed?
Adopting a simple RACI model (Responsible, Accountable, Consulted, Informed) helped us move faster and reduce drama. Everyone knows where they stand and how decisions are made.
For example:
- Designers and engineers are responsible for building a new pattern.
- The design system team is accountable for quality and alignment.
- Accessibility and brand teams are consulted for specific needs.
- PMs and leadership are informed as things go live.
It might feel “corporate,” but it clears up confusion and keeps progress moving.
4. Communicate Like a Product Team
A design system isn’t a static asset it’s a product. So treat its communication like product marketing.
That means:
- Publishing changelogs with context (not just version bumps).
- Writing clear release notes, not vague “updates.”
- Hosting regular office hours or drop-in demos.
- Creating internal landing pages where people can self-serve info.
One thing that’s worked well for us: tailoring messages to different roles. Engineers don’t want the same update as product designers. PMs care about adoption impact, not icon changes. Don’t just communicate frequently but communicate usefully.
5. Expect Pushback—and Design for It
Not everyone will love the system and that’s normal. Some teams want more control, others are skeptical of system constraints, and some just have competing priorities. Instead of taking pushback personally, treat it as a sign of engagement.
Ask:
- What would need to be true for this team to adopt the system?
- Are we being too rigid, or are we missing context?
- Can we support flexibility without breaking consistency?
When tensions do arise, go back to documented principles and user data. Show how decisions were made. Transparency beats defensiveness every time.
6. Prove Value, Then Keep Proving It
Stakeholders don’t stay convinced forever. You need to keep showing that the system works. Track and share:
- Component adoption rates
- Time saved in design or dev
- Bug reduction from standardisation
- Improvements in accessibility compliance
Even simple before/after comparisons help. One slide showing a fragmented UI replaced by a consistent pattern library can make the case better than a 10-minute pitch.
Final Thoughts
Stakeholder management isn’t fluff work whereas it’s the infrastructure to get the system running. If you want your design system to stick, scale, and actually make a difference, you have to invest in relationships just as much as you invest in tokens and components.
It’s not always glamorous. It’s often messy. But it’s the real work behind every design system that actually gets used.