The Problem with Ad-Hoc Design
Most teams still ship UI the way they did in 2018 — one-off mockups, inconsistent spacing, colors copied from Slack messages. The result is visual debt that compounds with every sprint. Components drift apart. Developers interpret specs differently. And the “design system” becomes a Figma file nobody updates.
This isn't a tooling problem — it's an architecture problem. When design decisions live in documents instead of code, they're already out of date by the time they ship.
“A design system isn't a deliverable. It's a living, versioned contract between design and engineering.”
Tokens Over Variables
Design tokens are the atomic unit of a system. They encode decisions — not just values. A token like --spacing-md carries intent that 16px never will.
When tokens are the source of truth, changes propagate instantly. Update a single value and every component, every screen, every breakpoint responds. No find-and-replace. No missed corners.
:root {
--color-primary: #FFD600;
--color-surface: #111111;
--spacing-unit: 8px;
--radius-sm: 4px;
--font-mono: "IBM Plex Mono";
}Component-First, Not Page-First
Pages are compositions. Components are the building blocks. When you design page-first, you end up with bespoke layouts that can't be reused. When you design component-first, pages assemble themselves.
The best systems we've seen treat components like industrial parts — standardized, interchangeable, rigorously tested. Each one has a clear API, documented states, and predictable behavior across contexts.
The Path Forward
Start small. Pick your five most-used components. Tokenize their colors, spacing, and typography. Wire them to a single source of truth. Ship that — then expand.
The teams that win aren't the ones with the most components. They're the ones with the most discipline. A design system is a practice, not a project.