Sainsbury's in-house system, covering five brands (Sainsbury's, Argos, Nectar, Habitat and Tu) with one headless component layer themed per brand through tokens.
Why we like it
Sainsbury's is a useful read on multi-brand because of how the system got there. Argos ran Bolt, a dev-first web components library with wide adoption but little design input. Sainsbury's ran Luna, a design-led library with accessibility guidance ahead of its component maturity. Rather than pick one, the team folded both into a unified system: a headless Global UI library at the core, with brand tokens layered on top via Token Studio so Sainsbury's, Argos, Nectar, Habitat and Tu each get a tuned output from the same components.
It's the sort of consolidation most retail groups put off because it's politically awkward, and the write-ups are candid about the trade-offs made along the way, which is why the system is worth following even if you'll never ship a loyalty card.
Where it fits
The Sainsbury's system fits large retailers running several consumer brands under one roof who need shared components without flattening the brands into each other. The multi-brand token architecture and the Figma-to-code pipeline through Token Studio are the parts most teams can learn from.
Good to know: Luna is being wound down in favor of Fable, the newer component library, so the public GitHub packages under jsainsburyplc/luna are a historical reference rather than an active project. The current thinking lives on the docs site.
Ideas to borrow
- 01.
Architecture
Build the core as a headless component layer and apply brand through tokens on top, so a merger of two existing libraries becomes a theming problem rather than a rewrite.
- 02.
Governance
When consolidating two sibling systems, keep the strengths of each (one's accessibility rigour, the other's developer adoption) rather than picking a winner, and name the trade-offs publicly as you go.
