S/03

Design systems

Tokens, components and the written rules that stop the tenth screen drifting away from the first.

TokensLibraryDocs

Right-sized, not impressive

A design system built for a company four times your size is a liability. It takes longer to learn than to ignore, and once a team starts ignoring it, it decays faster than having no system at all.

What gets built here is scoped to the product you have and the people who will maintain it. If that is nine components and forty tokens, it is nine components and forty tokens.

Naming that survives a rebrand

Tokens get named for their role — surface-raised, text-quiet, accent-action — not for their current value. When the brand changes, the values change and the four hundred references do not.

What you get

A token sheet, a component library with states documented, written rules for contribution, and a walkthrough session with your engineers.

What is included

A token set named for what things do, not what they currently look like
Components sized to your team, not to a theoretical enterprise
Documentation that lives beside the code so it stays current
A contribution model for adding the eleventh component without me

Two project slots open from September

Have you got something that deserves doing properly?

Tell me what is broken, who it is breaking for, and what happens if it stays that way. That is enough for me to come back with a scope and a number.