Designing components for a design system
Building Base UI as a flexible framework, enabling consistent yet customizable components to support diverse team needs
Project
As we developed the core foundation of Base UI, we simultaneously worked on new components and established the blueprints for how future components should be created. Our goal was not just to deliver a set of UI elements but to build a flexible and scalable design framework that could grow and adapt to the evolving needs of different teams and use cases.
This work required defining principles and structures that would ensure consistency while allowing teams to customize components without breaking the system. In particular, we focused on creating a framework that decouples key design decisions, allowing greater flexibility in how components are used and adapted.
Component design principles
Slot concept
Instead of building rigid, one-size-fits-all components, we designed a scaffolding system where certain sections (or “slots”) can be replaced with different atomic components.
- Why it matters: This ensures that teams can adapt and scale components without breaking design consistency.
- Example: A card component might have predefined slots for a header, content, and actions, but teams can swap out elements within those slots—such as replacing an image header with an icon or changing the action buttons—without altering the core structure of the card.
Decoupling layout from
purpose
Traditionally, components are often designed with a fixed layout that assumes a specific purpose, which can limit reusability. Instead, we introduced a framework that separates layout (spacing, structure, alignment) from the functional purpose of a component.
- Why it matters: This allows components to be reused in different contexts without needing to create multiple variations.
- Example: A card component should allow flexible content placement rather than forcing a rigid title-body-footer structure.
Separating breakpoints
from configuration
Many design systems hard-code breakpoints into component configurations, making them difficult to adapt across different screen sizes or product surfaces. We took an approach where breakpoints are managed separately, enabling a more responsive and scalable system.
- Why it matters: Teams can customize responsiveness without overriding component logic.
- Example: Instead of having different layout pre-determined for desktop and mobile, teams can combine different layouts to achieve responsive design.
Refactoring existing components
Refactoring complex
components
We redesigned previously complex and rigid components—such as the carousel—by breaking them into atomic modules, allowing for flexible composition tailored to specific needs.
- Why it matters: Components have single responsibility.
- Example: The original carousel was a combination of tabs and a carousel which created unnecessary complexity. To refine this, we worked closely with teams using the component to align on separating each subcomponents, ensuring the new structure can be configured to meet their needs while remaining scalable.
Refactoring sections
Rather than offering rigid, opinionated organism-level components, we introduced a flexible grid structure allowing designers to compose layouts using various atomic components. This approach ensures adaptability while maintaining consistency and scalability across different use cases.
- Why it matters: Single grid structure that powers all section layouts. We no longer have to maintain 8 different legacy custom sections.
- Example: Teams compose marketing pages, dashboards, and editorial layouts from the same grid primitives instead of forking new section templates per surface.
Design system adoption
Identifying stylistic
discrepancies
We performed a detailed and thorough audit of missing variants, states, and stylistic discrepancies across teams to provide all teams with a complete set of components for both existing and new designs.
Workflow: designing with
Base UI
Setting clear expectations and workflows was key to shifting the design organization’s approach. Through presentations and onboarding exercises, designers from various teams began using and contributing to Base UI.
Creating culture
There was no single method to achieve all our goals. From refining our communication strategy to streamlining the feature request form, we explored creative ways to ensure a smooth onboarding process for all teams.
Key takeaways
Designing for flexibility, not just function
In a dynamic, multi-brand environment, designing for one use case isn’t enough. Our focus shifted from building isolated components to creating a flexible framework that adapts to varied needs. Instead of hardcoding assumptions, we built structure around layout, spacing, and content slots—giving teams the freedom to assemble what they needed. This framework-first mindset turned our system into a creative foundation, not a rigid rulebook.
Why strong architecture drives adoption
A component is only as useful as it is understandable. When the logic behind how it’s built is unclear or inconsistent, teams hesitate—or worse, misuse it. We found that strong architecture, with clear patterns, naming, and slot behavior, made adoption easier and more reliable. Teams could trust the system, use it confidently, and even contribute back—because the rules made sense.
Embracing the spirit of atomic design
Atomic design isn’t just a structure—it’s a way of thinking. Breaking interfaces into atoms, molecules, and organisms gave us clarity, consistency, and modularity. More importantly, it helped us scale the system thoughtfully. By fully embracing its philosophy, we built a foundation that felt intentional—not just organized, but intuitive and future-proof.