Design tokens are a contract, not a palette
A token named after a colour tells you what it looks like. A token named after a role tells you what it promises. Only one of those survives a redesign.
Swatches describe, roles promise
“Blue-600” says what a colour is. “Text on action” says what it is for, and therefore what it must work with. When the brand changes, swatches change; roles stay, and the promises they carry should too.
Write the promise down
In Quire every role pair is tested: text on surface, text on action, focus ring on every surface. The contrast ratio is computed in CI and printed in the docs, next to the token.
If a change breaks a promise, the build fails. That is the contract.
Three layers
I use three layers: primitives (the actual colours), roles (what each colour is for) and surfaces (sections of a page that remap the roles, such as a dark band). Components only ever read roles.
This is also how dark mode becomes cheap: you remap the roles once, and every component follows.
Components only ever read roles.
Name for the reader of the code
The person reading your tokens is a developer at 5 p.m. on a Friday, fixing a bug. “--text-muted” helps them. “--grey-4” makes them guess.
— Mara
Reply by e-mailMore writing
Designing for 3 a.m.
Most interfaces are designed at 11 in the morning by rested people. Some are used at 3 at night by exhausted ones. Here is what changes.
The case for fewer alerts
Alert fatigue is a design problem, not a discipline problem. Four questions I ask before any notification ships.