Building a Palette

Most colour mistakes happen before a single pixel is placed. They happen when colours are chosen on the basis of aesthetics alone — “I like this blue, I’ll add this orange, maybe a touch of green” — without defining what each colour is for. A palette isn’t a mood board. It’s a system with rules: this colour for this purpose, that colour for that purpose, and no colour without a reason.

Start with the anchor

Every palette needs one anchor — the colour the entire system is built around. This is usually your primary brand colour: the one that appears on your logo, your primary buttons, your key interactive elements. Everything else in the palette should be selected in relation to this anchor.

The anchor doesn’t have to be vivid. Many successful design systems use a neutral anchor — a deep navy, a warm off-black, a cool slate — and reserve saturated colour for accents only. Apple’s default UI is built almost entirely from greys with selective use of blue for interactive elements. The restraint is the point: when everything is a neutral, the moments of colour carry enormous weight.

Neutrals carry the work

In most interfaces, 80–90% of pixels are neutral: background surfaces, text, borders, dividers, shadows. Neutrals deserve as much care as accent colours. A flat grey (#808080) looks harsh and artificial in most contexts. A blue-tinted grey (hsl(220, 9%, 45%)) reads as sophisticated and intentional. The warmth or coolness of your neutrals should complement your accent — warm accents with warm neutrals, cool accents with cool neutrals or a deliberate tension.

Define a neutral family early: a near-white for backgrounds, a light grey for secondary surfaces, a mid-grey for borders and dividers, a dark grey for secondary text, and a near-black for primary text. This family should be consistent enough that elements look unified, but varied enough that hierarchy is visible without colour.

A warm-tinted neutral family for a warm brand context might look like:

--colour-surface:         hsl(40, 10%, 99%);  /* page background */
--colour-surface-raised:  hsl(40,  8%, 96%);  /* cards, secondary surfaces */
--colour-border:          hsl(40,  6%, 88%);  /* dividers, input borders */
--colour-text-secondary:  hsl(40,  5%, 45%);  /* captions, metadata */
--colour-text-primary:    hsl(40,  8%, 15%);  /* body text */

The hue (40°) gives warmth throughout. Saturation decreases as values approach pure neutral. Check every pairing: text-primary on surface should achieve at least 7:1 for body text; text-secondary on surface should achieve at least 4.5:1. A cool-tinted system shifts the hue toward 220°; a fully neutral system drops saturation to 0–4%.

Define roles before assigning colours

Before you assign any colour values, write out the roles your palette needs to fill: primary action, destructive action, success state, warning state, error state, selected state, disabled state, link colour, focus ring. This list is your spec.

Only once you have the role list should you assign colours. This order matters. If you start with colours, you’ll find yourself retrofitting roles onto aesthetic choices, ending up with a blue-for-primary that happens to look like an error state in certain contexts, or an accent that works for links but conflicts with success states. See colour in UI systems for how semantic roles translate to interface patterns.

Testing your palette

A palette is untested until you’ve seen it fail. Put your colour combination through these checks before committing: run every text-on-background combination through a contrast checker (colour accessibility); simulate the palette under deuteranopia (red-green colour blindness) using a browser extension or Figma’s accessibility view; render it at small size and at large size, since saturation that reads beautifully at display size can feel jarring at body size; and check it in dark mode, which requires a different palette approach entirely. Most palettes that “look great” in design reviews fail one or more of these tests.