Colour Theory at Scale: How We Built ColoursUI

Colour Is Engineering

Design systems often treat colour as an aesthetic decision and a technical afterthought. The token gets a hex value, the hex value goes into the design file, and the designer and developer argue periodically about whether the implementation matches the intention.

At RCWMAS, building ColoursUI taught us that colour at scale is an engineering problem with a design surface — and that treating it as anything less produces systems that degrade over time.

Perceptual Uniformity

The first principle we built from was perceptual uniformity. Two colours with the same mathematical distance in RGB space do not look the same distance apart to a human observer. Blue lightens more aggressively than red; green occupies a wider perceptual band than either.

The practical implication: palettes built in RGB or HSL inevitably look uneven. We generate our palette steps in the OKLCH colour space, which models human colour perception more accurately.

/ OKLCH: lightness, chroma, hue /
--violet-500: oklch(0.54 0.23 295deg);
--violet-600: oklch(0.47 0.25 293deg);
--violet-700: oklch(0.40 0.24 291deg);

The result is palette steps that look visually equidistant — making it far easier for designers to reason about tint and shade choices without reaching for a colour picker.

Accessible Contrast Ratios

WCAG 2.1 defines minimum contrast ratios for text legibility: 4.5:1 for normal text, 3:1 for large text. Building a palette in OKLCH makes it tractable to bake these guarantees into the palette generation:

1. Fix the background surface colour 2. For each semantic text role, calculate the minimum OKLCH lightness delta that satisfies the WCAG threshold 3. Lock that as the minimum step distance in the palette

When the palette is regenerated (for white-label or dark mode), the contrast guarantees carry through automatically.

The Token Pipeline

ColoursUI's token pipeline converts OKLCH source values into multiple output formats:

CSS custom properties (consumed by web products)

Tailwind configuration (consumed by utility-class-based builds)

Swift constants (consumed by iOS)

Compose tokens (consumed by Android)

Figma variables (consumed by designers)

A single source of truth. No manual synchronisation. No version skew.

What We Would Do Differently

The investment in automated pipeline tooling was absolutely worthwhile, but we underestimated the time required to educate teams on why primitive tokens should never be consumed directly.

The governance model — explicit, documented, with automated enforcement — should have been set up before the first consumer team onboarded, not in response to the first violation.

ColoursUI is available as an open design system for teams building consistent, accessible, multi-platform interfaces.