One design system, a whole brand portfolio

A brand portfolio is a design problem disguised as an organisational one. Brands sold into different markets, each with its own interface work, meant the same components existed many times over in many slightly different states.

The cost never appeared as a line item. It showed up as the same accessibility fix being made three times, as a component that behaved one way on a product page and another way in the app, and as any new market launch starting from a blank file rather than from a library.

The brief was not "make it look better". It was: make brand difference cheap, and make everything else shared.

We separated what a brand is from what a component does.

Brand identity became data: a token set describing colour, typography, radius, spacing and elevation. Component behaviour became shared: one date picker, one form field, one navigation pattern, consuming whichever token set is active.

The practical consequence is that adding another brand is a theme file, not a project. And a fix to the shared layer reaches every brand in one release instead of a dozen.

Token architecture. Three tiers — primitive values, semantic roles, component-level aliases — so a brand change touches the semantic layer and nothing below it.

Component library. Interface components documented with their states, their accessibility contract and the tokens they consume, kept in Figma-to-code parity.

Documentation. Written for the person implementing at 6pm on a Friday: what the component is for, when not to use it, and what breaks if you fork it.

Governance. The part most systems skip. Who can propose a component, who approves it, how a brand requests an exception and how deprecations are communicated.

The architecture is in production across the portfolio and has since been extended to a second manufacturing group. Figures the clients have cleared for publication are below; the rest sit under NDA.