A design system, not a folder of components.

The ask was a folder of shared components. I initiated the work to build the system underneath it — tokens, a contribution path, and the governance that keeps a component library from fracturing into forks — for a federal CIO organization’s digital products.

Tokens, the component library, and Storybook — visuals to come.

The ask

The dev team wanted to share a repo so people would stop rebuilding buttons. Reasonable — and about a tenth of the problem. A shared repo with no tokens, no contribution path, and no review process becomes nine forks inside a year. I initiated the work to build the system the repo implied but didn’t contain.

What a system actually needs

A real system is governance as much as it is code. I set up the contribution process — how a team proposes a component, how it gets reviewed, how it lands — and the review that keeps quality from drifting. I specified, researched, and reviewed the components; a front-end developer built them. That division kept design intent and engineering reality honest with each other.

The pipeline

Figma as the source of truth. Style Dictionary carrying tokens into code. An Angular component library. Storybook as the documentation both sides actually read. And Backstage scaffolding, so a new application starts with the system already in it — rather than opting into it later, once the shortcuts have already hardened.

What’s true, and what isn’t

In use across multiple programs and several released products. Governance is established and young: the contribution process works, but it hasn’t yet been stress-tested by a team that badly wants an exception. There are no adoption metrics yet — that, and the first real fight over an exception, are next year’s problem.