Token Architecture for Multi-Brand

The Omni design system at GSK needed to serve five distinct product domains — GSKpro (commercial platform), Email, Medical, Data, and Core — each with its own visual requirements and brand constraints. The original token architecture was flat and brand-specific, with no principled way to share foundations across domains while allowing each to diverge where needed.

Each sub-system (OmniGSKpro, OmniEmail, OmniMedical, OmniData) had colour palettes and typographic requirements dictated by different business units and regulatory contexts. Medical products required specific accessibility thresholds and conservative styling, while the commercial platform needed more expressive brand elements. A single-brand token model couldn't accommodate this diversity without forking the entire system.

I designed a three-tier token architecture: primitives at the base (raw colour values, spacing steps, type sizes — shared globally), semantic tokens in the middle (purpose-driven aliases like background-primary, text-action that carried no domain-specific values), and component tokens at the top (scoped to individual components and always referencing semantic tokens). Domain themes were implemented as sets of semantic token overrides — each sub-system (OmniGSKpro, OmniMedical, etc.) remapped semantic tokens to different primitives without touching component definitions.

In Figma, the model used variable collections with modes mapped to each domain. Each sub-system had its own distinct colour identity while inheriting shared foundations from OmniCore. The token naming convention followed the unified Omni namespace — ensuring that whether a team was building for the medical platform or the commercial dashboard, they used the same token names and the system resolved the correct values for their context.

The multi-brand token architecture shipped across all five domains without requiring changes to component code. Domain switching was entirely a token concern — the component library remained a single maintained codebase. Teams could build and test features against any domain context by toggling a single configuration.

The Figma implementation made domain context explicit for designers, reducing inconsistencies caught late in review. The architecture's extensibility was validated when new domain requirements emerged — adding support required only a new token theme file rather than structural changes to the system. The approach became a reference model cited in internal presentations on how to scale design infrastructure across a large, regulated organisation.