Building Design Systems That Scale

The Problem With Ad-Hoc UI

Most product teams start with a handful of components and a shared colours file. Six months later, they have three shims for the same button and four interpretations of "primary colour." The design system conversation usually begins as a refactor and ends as a philosophy.

At RCWMAS we faced this problem across six simultaneous products. The answer was ColoursUI — not a component kit, but a layered token architecture with compiler-enforced contracts.

Layers of the Token System

ColoursUI separates concerns into three tiers:

Primitive tokens — raw values (hex colours, pixel sizes, weights). Never used directly in components.

Semantic tokens — intent-mapped aliases (--color-text-primary, --color-surface). Components consume only these.

Component tokens — component-specific overrides scoped to a namespace. Prevents bleed between design contexts.

The three-layer model means you can retheme an entire product by touching only the semantic tier — without touching a single component file.

Enforcing the Contract

A design system is only as good as its adoption. We use a combination of lint rules and TypeScript's type system to make "going off-piste" a compile error rather than a review comment.

// Bad — direct primitive consumption (lint error)
const label = ...;
// Good — semantic token via CSS variable
const label = ...;

Developer Experience Tradeoffs

Enforcing contracts adds friction early but removes ambiguity at scale. The teams that adapted fastest were those with the most cross-product work — they immediately valued a single source of truth over local shortcuts.

What We Learned

Design systems are not finished products. They are living contracts between design intent and implementation reality. The governance model — who can change a token and how — matters as much as the tokens themselves.

This article is part of an ongoing series on RCWMAS engineering decisions.