BMS Design System
The prototype for the UI we'll roll out across every BMS app. The shell you're looking at (sidebar, topbar, dropdowns) is the bms-ops skeleton; everything it's painted with comes from the token system below.
How this system is built
2-layer tokens
1. Primitive tokens — raw OKLCH color ramps, fonts and
scales in tokens.css. Exposed as Tailwind utilities
(bg-primary-600, text-danger-500).
2. Semantic tokens — meaning-carrying aliases in
semantic.css (--color-surface,
--color-text, --color-accent).
Components only reference these, so dark mode and future rebrands never touch a component.
3. Components — .btn,
.form-input, .card,
.badge in components.css,
built in that order: buttons set the language, forms inherit the rhythm, cards contain the rest.
Try the moon/sun toggle in the topbar — dark mode is a semantic-layer swap only.
Why OKLCH
perceptual
Every ramp shares one lightness/chroma spine — hue is the only thing that changes between
primary, danger, warning, success and info. A success-500 badge and a
danger-500 badge carry the same perceptual weight.
Within a ramp: hue constant, lightness falls smoothly 0.97 → 0.18, chroma peaks at the 500 mid-tone and tapers at both ends.
Dark mode narrows the lightness range (no pure black or white) and eases chroma, because color reads more saturated on dark surfaces. Hues never move.
References
How to build a design system in a weekend — the minimum viable system: tokens, a type scale, a spacing scale, and three components.
OKLCH from a UI designer's perspective — ramp construction, semantic hues, and dark-mode adaptation used here.