Growing a design system teams actually use

The starting point

When I took over Sable, it was a designer-led library of about 25 components. It had Storybook stories, but no automated tests, no linting, and no accessibility checks. Teams used it when it was convenient and built their own versions when it wasn't.

What I changed

I treated Sable as a product with developers as its users. That meant clear component APIs, sensible defaults, tokenized theming, and a release process teams could trust. Before adding anything new, I closed the quality gaps: every component now has unit tests and Storybook stories, and that coverage is at 100%.

Then I grew it based on what teams actually needed. Sable now has about 60 components. The biggest is the DataTable, which started simple and grew to handle custom sorting, custom cell rendering, nested sub-rows, and embedded data visualizations. Keeping that in one component, instead of splitting it into variants, is what makes it worth migrating to. Four applications use it today, and three more are moving to it from AG Grid.

Making adoption the default

A design system spreads fastest when starting a new project with it is the easy path. So I built blueprints: Next.js, React SPA, and micro-frontend starter projects with Sable and our architecture decisions already in place. One new team told us the Next.js blueprint and Sable saved them weeks getting to market.

The Community of Practice I run every other week is where Sable changes get reviewed and where teams tell us what they need next.

Results

• About 25 to about 60 components
• 7 product applications built on Sable
• 100% unit test and Storybook coverage, up from none
• 4 applications on the Sable DataTable, 3 more migrating from AG Grid

What's next

Automated accessibility testing. Today we surface accessibility issues through a Storybook add-on and a dedicated accessibility agent in our AI pull request review. The next step is making those checks fail the build.