A design system is not a component library. This is the single most important lesson we learned while building Meridian, a design system that now powers 14 products across 12 teams at a Fortune 100 financial services company. A component library is a collection of reusable UI elements. A design system is the living, breathing documentation of how your organization makes design decisions.
We started with the foundation: design tokens. Colors, spacing scales, typography, elevation, motion curves. Everything was defined as tokens first, implemented in code second. We used Style Dictionary to generate platform-specific token outputs from a single source of truth. When the brand team decided to refresh the primary color palette, we updated 3 token values and every product across web, iOS, and Android updated automatically in the next release cycle.
Component API design was where we spent the most deliberation time. Every component went through a proposal process: the team proposing the component had to submit at least three real usage examples from their product, document the component's API surface, and identify any overlap with existing components. This process added about a week to development time but prevented the proliferation of similar-but-slightly-different components that plagues most design systems.
Versioning and adoption tracking were crucial for long-term success. We implemented automated scanning that tracked which version of each component was used across all products. Teams that fell more than two major versions behind received automated nudges through their CI pipeline. We published a monthly adoption dashboard that showed component usage statistics, version distribution, and custom override frequency.
The governance model evolved over time. Initially, our core team of 4 built everything. As adoption grew, we moved to a federated model where product teams could contribute components through a standardized PR process. Core team members reviewed every contribution for API consistency, accessibility compliance, and documentation quality. This scaled the system from 50 to 200+ components without proportionally scaling the core team.
Topics