What Is a Design System and How Do Color Palettes Fit In?
A design system is the shared set of decisions, rules, and building blocks a team uses to design and build a product consistently. Color palettes fit into it as one of its most reused foundations: a palette becomes part of the system when its colors are named, stored as tokens, and given rules for where and how they may be used. If you only have a color swatch file that designers pick from by eye, you have a style reference, not a system.
The core parts of a design system
Most design systems are built from three layers that depend on each other:
- Tokens — named values for the smallest decisions: color, spacing, type size, radius, shadow, duration. A token is the single source of truth for a value, so changing it updates everything that references it.
- Components — reusable interface pieces (buttons, inputs, cards, navigation) assembled from tokens rather than hard-coded values.
- Guidelines — the written rules for when to use what: which color signals an error, how much contrast text needs, when a component variant is appropriate.
Color sits mostly in the token layer, but it reaches into both of the others. A button component consumes color tokens, and the guidelines decide which token a given state should use.
How a color palette becomes part of the system
A palette stops being decoration and starts being infrastructure when you do three things to it.
1. Name colors by role, not by appearance
blue-500 describes what a color looks like. color-action-primary describes what it does. Role-based names survive redesigns: if the brand blue shifts, color-action-primary still points at the right decision, while blue-500 becomes a lie. Keep a raw scale underneath (blue-100 … blue-900) and map roles onto it.
2. Separate primitives from semantic tokens
A two-tier structure keeps the system flexible:
| Tier | Example | Purpose |
|---|---|---|
| Primitive | blue-600 |
The raw value; never used directly in components |
| Semantic | color-text-link, color-surface-raised, color-feedback-danger |
The meaning; this is what components reference |
When dark mode or a new brand theme arrives, you remap semantic tokens to different primitives and every component follows without being touched.
3. Define states and contexts, not just base colors
Interactive elements need more than one color. A complete palette entry usually covers default, hover, active, focus, and disabled, plus how the color behaves on light and dark surfaces. Writing these down is what turns a palette into a rule set a team can follow.
Why accessibility belongs in the palette, not after it
Contrast is a property of color pairs, so it has to be decided at the palette level — retrofitting it later means re-auditing every component. Two practical consequences:
- Pair text and background tokens explicitly. Instead of leaving contrast to whoever builds the screen, define approved combinations (for example, which text tokens are allowed on
color-surface-raised). - Check contrast in a perceptually uniform space. Working in a space like HSLuv lets you adjust lightness while keeping perceived hue and saturation stable, which makes it far easier to hit a contrast target without the color shifting character. This is the approach behind HSLuv-based palette builders such as colorca, which is aimed at designing accessible color palettes for digital products in HSLuv color space.
The payoff is consistency: if every team pulls from the same accessible pairs, contrast stops being a per-screen gamble.
Design system vs. style guide
These get conflated, but they answer different questions.
| Style guide | Design system | |
|---|---|---|
| Contains | Visual rules: colors, type, spacing, tone | Tokens, components, guidelines, and often code |
| Format | Usually documentation | Documentation plus reusable, implemented assets |
| Enforces | How things should look | How things are actually built and kept in sync |
| Changes when | A designer updates the doc | A token or component changes and propagates |
A style guide can be a part of a design system, but on its own it doesn't give engineers anything to import. The test is simple: can a developer build a new screen using only system assets, without asking a designer for a hex value? If yes, you have a system.
A practical starting sequence
- Build a primitive color scale in a perceptually uniform space so lightness steps are even.
- Check candidate text/background pairs for contrast before committing them.
- Assign semantic roles (surface, text, border, action, feedback) on top of the scale.
- Document which roles may be combined, and which states each interactive role needs.
- Ship the tokens in a form both design and code can consume, so the palette has one source of truth.
Get the palette and its tokens right first — components and guidelines are much easier to keep consistent once color is no longer a per-screen decision.