Tokens, not utilities
Twenty-two semantic tokens named for intent (action, surface, border-subtle), not value (blue-600). Change a decision in one place and it propagates everywhere that meant it.
Case study 03
A design system small enough to actually use.
01 · The problem
A designer names a color "Primary / 600." An engineer names it --color-action. Same pixel, two names, two files that drift the moment either side moves.
Multiply that by every token, every state, every variant, and "design and engineering are out of sync" stops being a complaint and becomes math. Nobody decided to drift. The structure guarantees it.
02 · The approach
The system isn't a component library that happens to have tokens. It's a naming contract that happens to ship components.
Twenty-two semantic tokens named for intent (action, surface, border-subtle), not value (blue-600). Change a decision in one place and it propagates everywhere that meant it.
Every variant name in code is the exact name in Figma. A primary button is primary in both worlds. Handoff becomes a lookup, not a translation.
Lumen isn't an npm dependency. You copy the components into your codebase and own them. No version lock, no waiting on a maintainer, no inherited release cadence.
Hairline borders, restraint, room to breathe. Opinionated enough to feel considered, neutral enough to disappear into your product.
The interactive playground. Change a variant, watch the code update live.
03 · The numbers
handoff cycles
dependencies
components / tokens
teams and projects building on it
04 · Where it breaks
Four limits, honestly:
The moment you copy a component, you've forked it. Right trade for a solo designer. Wrong one for a fifty-person org.
Twenty-two semantic tokens encode a single point of view. Rebranding means editing tokens, not flipping a mode.
No data table, no date picker, no combobox. The hardest twenty percent of the work is a hundred percent ahead of me.
The restraint that makes Lumen feel considered makes it wrong for any brand that needs to be loud.