Design Systems at Scale

Build and scale a design system — components, tokens, and the rules that keep generated work on-brand.

Tokens, components, documentation and governance, from a first library through to something several teams share. I also encode the rules where the work happens, in the codebase — which is what makes the hundredth screen match the first, whether a person or an agent built it.

When you need this

Several teams are building the same components differently. A change to a button means finding every button. Designers argue about spacing in reviews. There's a component library that half the team ignores because it doesn't cover what they need. Or AI-generated code arrives off-brand, and nothing exists for it to check itself against.

How I run it

Tokens first — colour, spacing, type — because everything else derives from them. Then components, built to cover real cases rather than an idealised set.

Governance is where most systems fail. Who can add a component, what happens when someone needs something that doesn't exist, and how the system changes without breaking what's built on it. Without answers, a library rots into a folder of outdated symbols.

I also encode the rules where the work happens, in the codebase, not only in Figma. That's what makes the hundredth screen match the first whether a person or an agent built it — and it's the part that's newly urgent.

I built Smokeball's first Figma style guide, and this site runs on a published, machine-readable version of the same idea.

What you get

  • A token set with defined jobs, not just a palette
  • Components covering real cases, with states and edge cases
  • Governance: who changes what, and how
  • Rules written where the build process can read them

How the work runs

Six weeks upwards for a first system. Extending an existing one is usually faster. Adoption support afterwards matters more than the initial build.

Common questions

We have a library already. Is that a design system?

Not quite. A library is components. A system adds the rules for using them and the governance for changing them.

How do you get people to actually use it?

By building it from what teams already do rather than imposing an ideal, and by making the system the fastest route to a finished screen.

What does “machine-readable” mean in practice?

The tokens, module and rules live in a file an AI agent reads before writing code, so generated work starts on-brand rather than being corrected afterwards.

See the work behind this
Tell me what you’re building. I’ll tell you if I can help.
Email me →