10,000 m
The boardroom
A component library is a governance tool
Every large organisation has more products than designers, and every product team wants its own buttons. A shared design system is how you say no to that without a steering committee. It costs money to build and maintain, but it replaces hundreds of small arguments about colour and layout with one decision, made once and reused everywhere.
The real return is not consistency for its own sake. It is accessibility you only pay for once, faster delivery on every screen after the first, and a smaller surface for brand and compliance problems. Fund it as a product with a team, not as a side project for whoever is between assignments.
3,000 m
The architecture
Layer it on the platform, not around it
In a Salesforce estate, the design system should sit on top of SLDS rather than fight it. Use styling hooks and design tokens for brand colour, spacing and type, and build a small set of Lightning Web Components for the patterns SLDS does not cover. Anything that overrides base component internals will break on a release weekend, so treat those overrides as debt from day one.
A good design system is a standard people follow because it is the easy option.
300 m
The delivery team
Make the right thing the easy thing
Teams adopt a design system when it saves them time, not when it is mandated. Publish components in a package they can install, keep the documentation next to working examples, and answer questions in a channel within a day. If a team has to build a custom component, ask them to contribute it back rather than fork it.
Track adoption with something concrete, such as the share of new screens built from shared components. When a team keeps building its own, go and find out why. Usually the library is missing something they need, and that is far more useful to know than who broke the rule.
