Colour in UI Systems

A UI colour system is not a palette of colours you like — it is a grammar of meaning. Just as a period ends a sentence regardless of what the sentence says, a red error state communicates “something failed” regardless of what failed. Users learn this grammar implicitly by using software. Break it, and you break their ability to understand the interface. Follow it consistently, and the interface becomes legible before any text is read.

Semantic colour categories

The core semantic categories that most interface colour systems need to cover are: primary (the brand colour, used for primary actions and key interactive elements), neutral (the grey family covering surfaces, text, borders, and structural elements), success (confirmation that something worked — traditionally green), warning (caution that something requires attention — traditionally yellow or amber), danger/error (something failed or has destructive consequences — traditionally red), and info (neutral information that doesn’t require immediate action — traditionally blue).

Each category requires at minimum three values: a background tint (for banner backgrounds and input fills), a border colour (for the outline of alert boxes and input states), and a foreground colour (for icons and text within the element). Often you’ll also need a dark variant for text within the tinted background, since the background tint alone may not provide enough contrast for smaller text.

Status colour conventions

The status colour conventions (red=error, green=success, yellow=warning, blue=info) are so established in software that departing from them is rarely worth the cost. Users bring this vocabulary from email clients, IDEs, monitoring dashboards, form validation across the web, and operating systems. Every application that uses green for success reinforces the vocabulary.

When designing a status system, the question is not “what colour means success?” but “what specific shade of green creates the right success background, border, and text to meet our contrast requirements, match our brand neutrals in warmth/coolness, and read correctly on both light and dark surfaces?” The category is fixed; the specific values are the design decision.

Interactive state colours

Interactive elements — buttons, links, form inputs, checkboxes, toggles — each require a set of state colours: default, hover, active (pressed), focused, and disabled. These states are not just about colour change; they’re about communicating affordance and feedback. The sequence should be perceptible but not jarring.

A common pattern for primary button states: default (full brand colour, high contrast), hover (slightly darker — reduce lightness by 8–10%), active/pressed (darker still — a clear visual depression), focused (default colour with a high-contrast focus ring that meets 3:1 contrast against surrounding colours), disabled (reduced saturation and lightness — enough to signal inactivity without disappearing entirely). The disabled state is frequently under-designed — pure transparency or very low opacity often fails contrast requirements while suggesting the element doesn’t exist rather than that it’s temporarily unavailable.

Limiting the palette

One of the most common UI colour mistakes is palette sprawl — adding new colours whenever a new component needs a colour, without mapping the new colour to an existing category. After six months of this approach, you have 40 colours with no coherent structure, and every new component requires bespoke colour decisions.

The constraint that prevents this is defining the semantic palette before building components, then forcing every new colour need back into an existing category. If you genuinely need a new semantic category, add it to the palette explicitly. If a component needs a slightly different shade of an existing colour, use a tint or tone of the category colour rather than introducing a new hue. See systematic colour for how a scale-plus-token approach makes this constraint natural rather than forced.