Earning Trust: Our Journey to Stakeholder Buy-In for a Unified Design System

After months of effort—refining 70+ components, integrating tokens, and building a polished, consistent foundation—we were ready. Our goal was ambitious: bring consistency across platforms, accelerate dev time, cut design duplication, and improve the user experience across the board.

Technically, the library was sufficiently there. Strategically, it was aligned - at least at the leadership level. But organizationally? We still had a long way to go.

The Blueprint Looked Great. Reality Had Other Plans.

In theory, our design system was a smart investment. The pitch was clear: lower costs, faster shipping, consistent UX. What we didn’t fully account for was how varied—and personal—design and development workflows are across teams. Take project tracking methods for example: some teams used Jira, while other teams use Trello, and some others just used Confluence.

Each stakeholder had a different perspective: Design wanted creative freedom. PMs were laser-focused on delivery timelines. Engineers wanted fewer unknowns. To many, our system felt like one more tool to learn, one more process to follow—just more friction in a world already full of it. And no matter how well we organized our governance docs or how slick our roadmap looked, many teams saw it as overhead. Not a solution.

Too Much Talk, Not Enough Traction

We had leadership support. We showcased components. We shared Figma libraries. We expected excitement. Instead, we got silence. Or worse—teams quietly built their own components from scratch, ignoring the system entirely.

One designer told me candidly, “We love the idea, but we don’t have time to learn a whole new setup. We’re trying to launch.”

That’s when it clicked: our strategy needed to change. If we wanted adoption, we had to meet teams where they were.

Shifting Gears: From Selling to Solving

We stopped trying to “evangelize the org” and started asking better questions: What’s making your process harder? What’s causing bugs? What’s eating up time?

One team at a time, we listened. Then we showed—not told—how the system could help. We didn’t ask teams to trust us blindly. We worked on their features, built the missing pieces, and proved the value within their real-world workflows. We stopped pitching theory. We started building side-by-side.

And it worked. Adopting a single design system form component saved one team 30 hours of development. That got people’s attention

Winning Hearts, One Project at a Time

This wasn’t a shiny launch moment. It was a series of messy, collaborative sprints. There were doubts. There were roadblocks. Teams pushed back—hard.

But we stayed in the room. We rewrote confusing docs. We tweaked designs that didn’t quite fit. We sat in sprint reviews and paired with devs. We adjusted our process when we got it wrong.

And slowly, we earned trust—not because we had the perfect system, but because we showed up, iterated, and adapted.

When the Design System Became “Ours”

The turning point came when the system stopped being the design team’s thing and started becoming a shared asset. Designers started coming to our team proactively showing us their product roadmap, asking "how can I use the design system components in my design?"

That's when we introduced more concrete rituals: regular sync between Shared Tech and teams, formal design process, governance committee, feedback loops, JIRA templates for creating new components.

As each team's engineering was supported to build their project using our components, and designers proposed incremental changes to the library, it wasn’t “the system” anymore—it was just how we worked.

What We’d Do Differently

Looking back, there are things we’d absolutely change:

• We shouldn’t have jumped straight into technical details with teams who weren’t ready.

• We should’ve spent more time understanding team roadmaps and resource limitations.

• We needed to be clearer about what onboarding involved—and what kind of support teams could expect.

• Most of all, we underestimated the human side. A design system changes how people work. And that means emotions, turf, habits, and trust all come into play.

It wasn’t just about components—it was about change.

Was It Worth It?

Yes—without a doubt.

Our design system is no longer a proposal, a pilot, or a pitch. It’s part of our product foundation. It helps teams move faster, with less rework, and with a more consistent experience for users.

There’s still more to do. We’re still migrating legacy flows. We’re still evolving accessibility support. But we’re over the hump.

We’re not asking teams to try it out anymore. They expect it.

And earning that expectation? That was the real work.