What is A Design System
Design systems are often misunderstood. Many people see them simply as collections of visual styles or reusable components—but they're actually much more than that! A great design system is a new way of developing products. It breaks down barriers between designers and developers, cuts down on repetitive work, and boosts quality across your products. Here’s how we transformed Base UI from just a basic library into a powerful, scalable system used by all our Battle.net teams—and some lessons we learned along the way.
A Look Back: Shared Tech and Early Lessons
Base UI’s origins go back to the Witch Craft team, which was formed to help spin up multiple game sites more efficiently. The team created a series of templates and related components that allowed designers to build pages by assembling pre-made sections and handing them off to engineers. This worked well—at first.
But as we expanded the system beyond franchise teams, problems emerged:
Components weren't built consistently
Templates were rigid and tough to adapt
Without design tokens, styling became messy and repetitive
Teams outside our core group struggled to use the library
They also didn’t know how to contribute back to the library
The takeaway? A shared library isn’t enough. We needed a true design system—one that could scale across teams, products, and future requirements.
Why Base UI Needed to Evolve
A key reason to invest in a stronger system was to stop reinventing the wheel. Designers were regularly starting from scratch, spending time defining details like button states and hover styles—things that should’ve been standardized. We also saw:
There is a lot of wasted time re-solving the same problems
Without a centralized system, every new project often starts from scratch—even for common interface patterns. Designers re-create the same dropdowns, buttons, and form elements, spending hours on visual details instead of tackling the core user experience. These micro-decisions accumulate into major inefficiencies. A scalable system like Base UI helps eliminate this redundancy by providing ready-to-use, well-documented components that can be adapted as needed.
There were so many stylistic discrepancies that would never be prioritized
When teams work in isolation, small visual inconsistencies—like slightly different shades of gray, font weights, or button styles—inevitably creep in. These aren’t “urgent” issues, so they rarely get addressed. But over time, they fragment the product’s visual identity and erode user trust. Base UI provides a shared visual language that aligns all teams and ensures the product feels cohesive, regardless of who worked on what.
Maintenance becomes a nightmare
Designers often rely on outdated files, scattered documentation, or the browser inspector just to figure out how a component behaves. This creates a huge gap in understanding and slows everyone down. With Base UI, we emphasized maintaining a single source of truth—documentation that is always in sync with both design and code. This reduces guesswork and keeps teams focused on building, not deciphering.
Looming branding overhaul request from Game Pass
While everything might appear “good enough” today, we needed to modernize our entire front-end infrastructure with Microsoft acquisition and potential changes in branding strategy. Base UI wasn’t just a design decision—it became a strategic foundation for future-proofing our products. By investing early in a scalable system, we positioned ourselves to respond quickly and confidently when large changes hit.
Defining Base UI as a True Design System
Once we have aligned on developing Base UI into a true design system, Base UI’s next chapter wasn’t just about making better components. It was about creating a systematic approach to building products—anchored in shared principles, tools, and workflows. Here’s what that looked like:
Design principles and style guides — Setting the tone for colors, typography, voice, and tone.
Design tokens — Translating those principles into a structured format to support themes and multi-brand needs. Read more about design tokens and how we built them.
Component libraries — Reusable pieces built in Figma and Storybook, always synced with code. Read more about atomic design principles and how we made our components more flexible and robust.
Documentation — Clear, accessible guides for how to use each component and apply the system. Read more about how we approached documentation.
Governance — A model for how teams contribute, maintain, and evolve the system together. Read more about challenges of a multi-brand design system team.
This holistic approach turned Base UI into more than just a toolbox—it became a product in itself.
What Happens When a Design System Works
When Base UI started gaining traction, the benefits were clear:
Designers Shift Their Focus
When Base UI became a fully functional design system, it reshaped the expectations for designers. Those building the system shifted into more technical, systems-thinking roles. They began considering not just how something looks, but how it can be reused, scaled, and implemented consistently in code. It required a mindset of design as infrastructure.
For designers using the system, the shift was just as meaningful. With foundational decisions already made, they could focus on experience-level thinking—crafting flows, refining storytelling, and optimizing usability. Instead of asking “what should this button look like?”, they could ask “how do we solve this user problem more elegantly?” This division of focus made space for both rigor and creativity.
A Shared Language Emerges
Before Base UI, designers and developers had different interpretations of the same component—leading to miscommunication, rework, and frustration. But with the design system in place, both teams worked from the same source of truth. Design tokens created a shared language, and component documentation clarified behavior and edge cases.
This alignment didn’t just improve handoffs—it reduced the need for them altogether. Designers could point to a specific component in Figma, and developers knew exactly where to find its coded counterpart. It made collaboration more fluid and less reliant on long-form specs or one-off conversations.
Iteration Speeds Up
Design velocity increased dramatically with Base UI. Instead of building every screen from scratch, teams now assembled products using pre-built, well-tested components. Because the system accounted for common interaction states and accessibility patterns, reviews and QA cycles also sped up.
This was especially valuable in fast-paced environments where features needed to ship quickly. Having the building blocks ready meant teams could focus on refining the user journey rather than solving for the basics.
Work Scales Across Teams
One of the most powerful effects of Base UI was how it enabled cross-team efficiency. If the onboarding team solved a design problem—say, an alert pattern or a complex input interaction—those solutions could now be used by marketing, support, or content teams without duplicating effort.
As more teams contributed to and adopted the system, the value of Base UI compounded. It became a network of shared solutions, where every improvement had the potential to benefit the entire organization.
Treating the System Like a Product
Base UI only created value once teams started using it. That’s why we had to think of it not just as an internal tool—but as a product with users. That meant investing in things like:
Marketing why the team should use the design system
Adoption didn’t happen just because Base UI existed—it had to be championed. We needed to empathize with other teams’ concerns: tight timelines, limited resources, and fear of losing creative control. So we focused on storytelling—framing the system not as a constraint, but as a tool that freed teams from tedious UI decisions and gave them more time to innovate.
We also emphasized real-world wins: time saved, consistency gained, bugs reduced. This helped teams see Base UI not as “extra work,” but as a strategic advantage. Read more about selling a design system.
Onboarding experience
Base UI wasn’t intuitive for everyone on day one. We had to meet teams where they were—some needed detailed walkthroughs, others just needed access and quick-start docs. We created custom onboarding experiences depending on a team’s maturity and their familiarity with design systems.
Some teams benefited from hands-on workshops; others needed one-on-one support. Over time, we realized the need to standardize this experience to scale better, while still maintaining a sense of personal support during the early stages.
Documentation as self-serve mode
Early versions of Base UI documentation were intentionally lightweight, tailored for a small group of expert users. But as the system scaled, gaps became apparent. Teams needed more clarity on component behavior, usage guidelines, and implementation tips—especially as new hires or less experienced users came onboard.
We expanded the documentation to include interactive examples, Figma links, design tokens, and do’s and don’ts. We wanted any user—regardless of background—to feel empowered to use the system without needing to DM someone for help. Read more about thinking of design systems documentation as a product.
Troubleshooting and customer support
As adoption grew, so did the demand for support. In the early days, we took a “white-glove” approach—pairing closely with teams to answer questions, solve problems, and gather feedback. This was invaluable for building trust.
Eventually, though, we needed to scale our support model. We introduced an internal help desk, office hours, and documentation updates based on repeated questions. The goal was to provide the same high level of support—but in a way that could grow with our user base.
Final Thoughts
A design system isn’t just a toolkit—it’s infrastructure. And like any infrastructure, it needs to be thoughtfully designed, well-documented, and maintained. It should empower teams, not burden them. At its best, a system like Base UI helps teams move faster, stay aligned, and build better products—together.
Building a true design system takes time, but it’s worth it. Because when everyone’s using the same building blocks, they’re finally free to focus on what really matters: designing great experiences.