A screen is a moment. A system is what makes the next hundred moments coherent.
When product designers design in isolation, they solve for the screen currently in front of them. The result is visual entropy: 20 slightly different button heights, 8 distinct font sizes for table headers, and an impossible cognitive load on engineers who have to guess which variation was intended.
1. Tokens as living agreements Before placing a single component, map the decisions the product must make: - What deserves primary contrast? - What should be scanned quickly? - What happens when data is missing or empty? - How does the interface explain a transition of state?
These decisions become design tokens before they become pixels. In Tailwind CSS v4, we define our tokens directly using `@theme inline`. This creates a single source of truth shared seamlessly between designers and engineers.
2. The power of semantic naming Never name tokens after physical colors (e.g. `blue-500`, `gray-200`). Always name tokens after their semantic role: - `--color-surface-elevated` - `--color-text-muted` - `--color-action-primary` - `--color-border-subtle`
When you support dark mode, high-contrast themes, or white-label customer skins, semantic tokens allow the interface to transform instantly without touching a single line of component code.
3. Accessible by construction Accessibility is not something you "audit and fix" at the end of a project; it is the fundamental structure of good UI. When you build atop verified headless primitives like Radix UI or Base UI: - Keyboard navigation (Tab, Arrow keys, Esc) works out of the box. - Screen readers receive appropriate ARIA roles and live announcements. - Focus rings are calibrated to meet APCA contrast ratios.
Design systems are not museums of polished parts. They are working agreements between human beings. Keep them lightweight, document the reasoning, and let the system evolve with the real questions your users are asking.