Challenges of A Design Systems Team
Rolling out a design system like Base UI in a mature organization is not just a design or engineering effort — it’s a cultural one. While the technical challenges of building components are real, the harder problems often lie in navigating organizational inertia, aligning priorities, and changing mindsets. Here are some of the key challenges we faced as a design systems team, and how we tackled them.
The Fear of Losing Creative Freedom
One of the earliest pushbacks we heard was that a design system would limit creativity. Designers worried that Base UI would become a rigid box — optimized for efficiency but stifling nuance and exploration.
This fear is valid, especially if the system becomes too prescriptive or lacks flexibility. But the reality is, when a design system fails to offer the right solution for a problem, it’s not the fault of the designer — it’s a gap in the system. Our job as system builders is to close those gaps over time while keeping the doors open for edge cases and experiments. We had to continually reinforce that Base UI was not the ceiling for design — it was the floor. A solid starting point, not a limit.
Getting Buy-In from Partner Teams
Many of our partner teams were already overwhelmed — short on design bandwidth, deep in roadmaps, and hesitant to take on anything “extra.” Learning a new system felt like a tax.
To make adoption easier, we stopped expecting teams to come to us and started looking for the right entry points. We identified opportunistic projects — redesigns, refactors, or greenfield features — where using Base UI could solve real problems without adding unnecessary overhead. In some cases, our team even embedded directly into their workflow to help accelerate the initial lift. This helped show the value of the system in action, not just in theory.
Creating Alignment Across Siloed Teams
One of the biggest reasons Base UI was needed in the first place was the inconsistency across products — each team had built their own version of a button, a card, or a layout pattern. And each team had done it in isolation.
Because we weren’t in charge of every product’s roadmap or visual direction, we had to find ways to foster alignment without direct authority. We initiated regular syncs, built cross-functional working groups, and started to broadcast our roadmap where design and engineering teams could see how Base UI was evolving and what was coming. Alignment didn’t happen overnight, but over time, teams began to look to each other — and to the system — before going solo.
Keeping Track of Everyone’s Roadmaps
To make Base UI genuinely useful, we had to stay ahead of upcoming product needs. If a team was planning a new feature that required a component we didn’t yet have, we wanted to bake that into our roadmap — not let them build something one-off just to meet a deadline.
This required proactive relationship-building. I made it part of my role as design lead to keep tabs on upcoming product initiatives across the organization. That way, we could fold Base UI into the project timeline early — and avoid the scenario where we’re scrambling to catch up or clean up later.
Connecting the Dots Across the Organization
In a large org, there’s often no single person who has visibility into everything. But as the design systems team, we were in a unique position to see horizontally across all product teams, and vertically across design, engineering, and leadership.
That perspective became one of our superpowers. We could spot when two teams were solving the same problem differently — and bring them together. We could identify repeatable patterns across projects and extract them into shared components. But this didn’t happen passively. It required deliberate effort to stay in the loop — joining roadmap reviews, attending standups, listening more than we talked.
Feeling the Pressure to Do Everything for Everyone
Early on, before Base UI gained traction, our team was spread thin. We were building foundational components while simultaneously acting as consultants, educators, and even front-line designers for other teams. In trying to demonstrate value, we often ended up doing the work ourselves — building components for other teams and hoping they’d pick up the system from there.
While this was unsustainable, it did help us seed the system across the organization. The key was making sure these engagements weren’t just one-off favors but educational moments. We paired closely with teams, walked them through the reasoning behind the design decisions, and used the experience to grow our documentation and identify gaps in the system.
Establishing a Governance Model That Scales
As more teams began adopting Base UI, questions around ownership and decision-making started to surface. Who approves new components? Who maintains them? Can any team contribute directly to the system?
Early on, our systems team acted as the gatekeeper — we reviewed every contribution and made most decisions internally. But as adoption scaled, that model began to break down. We became a bottleneck, and the centralized model didn’t reflect the decentralized nature of how design decisions were actually being made.
We realized we needed a more scalable and transparent governance model — one that allowed for distributed contributions but still ensured quality and consistency. We began experimenting with a few practices:
Working groups for new components, where a lead designer and engineer is appointed, and they form a working group made up of representatives from different product teams
Proposal templates to standardize how new components or changes were requested
Design reviews with a focus on alignment, not approval — encouraging shared ownership
The key was shifting our role from gatekeepers to guides — helping teams make good decisions, not making all the decisions ourselves. It also meant being okay with saying “no” when a component didn’t serve shared needs, and instead offering better paths forward.
Becoming Stewards, Not Gatekeepers
As adoption grew, we had to shift our mindset from “system owners” to “system stewards.” We couldn’t (and shouldn’t) make every stylistic decision across every product. Teams needed autonomy. But that autonomy had to come with alignment.
We focused on building a shared language and nudging teams to communicate design decisions with each other. This took time and required a cultural shift. Instead of asking teams to follow our direction, we started facilitating conversations between them — creating spaces to share, discuss, and standardize when appropriate. We moved from being enforcers to being connectors.
Measuring the Impact of Base UI
One of the most difficult challenges — but also one of the most important — was proving the value of Base UI. Leadership wanted to understand: was the investment paying off?
Unlike features tied directly to revenue, the success of a design system shows up in indirect ways — faster development, more consistent UIs, reduced design debt, fewer bugs. So we had to get creative with how we measured and communicated impact.
We tracked a few core metrics:
Adoption rate: How many teams were actively using Base UI components in production.
Component usage: Which components were most used, and where gaps still existed.
Design-to-dev handoff efficiency: How many design hours and dev hours were saved through reusable components.
Support load: Reduction in custom component requests or duplicated design work.
Time-to-ship: Comparing projects using Base UI versus those that didn’t, looking at speed and effort.
We also surfaced qualitative wins: fewer bugs during QA, improved accessibility out of the box, or stronger alignment between design and engineering teams.
Perhaps most powerfully, we shared before-and-after stories — side-by-side comparisons of products pre- and post-adoption. These visual case studies spoke louder than charts and helped drive home the value of a shared system.
Wrapping Up
Rolling out Base UI wasn’t just about building a library of components — it was about shifting how our organization thinks, collaborates, and builds products. The technical work was only half the challenge. The real complexity came from navigating teams with different needs, priorities, and levels of readiness. As a design systems team, we had to wear many hats: builders, educators, connectors, and advocates. We learned to start small, build trust through real value, and evolve from gatekeepers to stewards of a shared foundation. For any team taking on a design system in a mature organization, the biggest takeaway is this: success isn’t just measured by adoption, but by the relationships you build and the momentum you create.