Visual drift in admin interfaces rarely comes from one big change. It comes from colour values, spacing and one-off components scattered across the codebase: the same “success” appears in three shades of green, and switching themes means touching dozens of files.
admin-design starts from tokens and shells, and only then talks about pages.
Colour describes purpose, not values
Colour goes through semantic utility classes only: bg-card, text-muted-foreground, text-success, border-destructive. Changing the theme changes tokens, not business code.
Palettes work in two layers: six presets (teal, blue, forest, violet, amber, graphite, plus custom) set the overall tone, while base colours (neutral, stone, zinc and others) and theme colours across eighteen hues fine-tune it. Light and dark modes keep separate choices.
Accessibility is not an add-on: font scale, font weight, high contrast, colour-vision support, reduced motion and underlined links all live in settings. Preferences stay in the browser and never enter business data.
Every chart is hand-drawn SVG
Line, bar, donut, mini bar, horizontal bar, heatmap, radar, funnel and Gantt charts share one set of semantic colours, follow light and dark modes automatically, and carry role="img" with an aria-label that says what the chart is showing.
The price of zero dependencies is maintaining coordinates and scales yourself. The return is control over bundle size, audits and theme consistency: there is no second colour system to keep in sync.
The component gallery is the acceptance surface
Nine component categories live on nine pages, and every control has a real placement. Changing a component means updating its gallery example first; a new capability ships as a gallery example, a real placement and a test. Documentation cannot drift from the implementation, and review has one place to compare against.