Design Systems: Tokens, Components, and Staying On Brand
Why tokens come before components, what a component spec must include, and how to scope a system to your organization.
A design system is the difference between a site that stays sharp for five years and one that drifts into inconsistency by the third campaign. It is not a style guide PDF. It is a working set of tokens, components, and rules that both designers and developers build from.
Key takeaways
- Tokens for color, type, spacing, and motion are the foundation everything else inherits.
- Components should encode states and accessibility, not just appearance.
- Documentation is what makes a system usable by people who did not build it.
- The return is speed: new pages ship in days and stay on brand automatically.
Start with tokens, not components
Tokens are the named primitives — brand colors, semantic colors, type scale, spacing scale, radii, shadows, motion durations. Defining them first means a rebrand or a dark mode is a token change rather than a hunt through hundreds of files.
Name tokens by role rather than appearance. A token called "surface-raised" survives a palette change; one called "light-gray-2" does not.
- Semantic color roles: background, surface, foreground, muted, primary, destructive.
- A constrained type scale with defined line heights and weights.
- A spacing scale on a consistent rhythm.
- Border radii, shadows, and motion durations as named values.
Discipline: If a component contains a hard-coded hex value or an arbitrary pixel measurement, the system has a hole. Every visual decision should trace back to a token.
Components carry behavior, not just looks
A properly specified component defines every state — default, hover, focus-visible, active, disabled, loading, error, and empty — plus keyboard behavior and the accessible name. That specification is what prevents each new page from reinventing a slightly different button.
Build the small set first: button, input, select, card, dialog, navigation, table. Composite patterns then assemble from those primitives instead of being drawn from scratch.
Keep design and code in sync
Systems fail when the design library and the coded components diverge. Keep them aligned by treating the code as the source of truth for behavior and the design file as the source of truth for visual intent, with tokens shared between them.
Version the system, publish a changelog, and review it on a schedule. Contribution rules matter: define who can add a component, what documentation it needs, and how deprecations are handled.
- Shared token definitions consumed by both design and code.
- A component gallery developers can browse.
- A written contribution and deprecation process.
- Semantic versioning with a visible changelog.
Scope it to the organization
A five-page marketing site does not need a formal system; it needs consistent tokens and a handful of reusable components. A multi-brand organization with several product surfaces needs governance, contribution workflow, and dedicated ownership.
Build the smallest system that solves your actual coordination problem, then let it grow with demonstrated need. Over-engineered systems get abandoned faster than under-engineered ones.
Measuring the return
Track time to ship a new page, the number of distinct button and input variants in production, accessibility findings per release, and how long a visual change takes to propagate. Those numbers make the system’s value visible to people who are not looking at the design files.
Frequently asked questions
Should we build on an existing component library?
Usually yes. Starting from an accessible headless library and applying your tokens gets you a robust system far faster than building primitives from zero.
Who owns the system?
Someone must, by name. Shared ownership across a team without a named steward is how systems quietly rot.
Ready to move on this?
We deliver design systems as part of larger builds and as standalone engagements, including tokens, components, and documentation. Tell us how many surfaces you need to keep consistent.