Case Study
IHG Multi-brand Design System
One set of core design foundations, tokens, components, and standards, that roughly 28 IHG hotel brands build from, where a brand's identity is a theme, not a fork.
- Role
- Lead Product Designer
- Team
- 3 designers · 5 engineers
- Stack
- Angular · Storybook · Builder.io
- Year
- 2025
01 · The challenge
The same UI, rebuilt brand by brand
IHG operates a portfolio of roughly 28 hotel brands, spanning luxury names like Regent, premium brands like voco, and mainstream brands like Holiday Inn.
Every brand carries its own distinct visual identity, but their digital products were being designed and built brand by brand, with no shared foundation underneath.
The result was duplication at portfolio scale: the same button, card, and form rebuilt many times over, drifting out of sync, slowing every team, and making consistency and accessibility impossible to guarantee.
02 · Goals
What the system had to do
- 1
One shared component library every IHG brand can adopt, eliminating per-brand rebuilds of the same UI.
- 2
Brand identity as configuration, not a fork a brand should be a theme, not a separate codebase.
- 3
A structure the system can scale across so onboarding a new brand is a new theme, not a new project.
- 4
Faster launches cut the effort to launch or restyle a brand's UI from a multi-week build to applying a theme.
- 5
A single source of truth that engineering and brand teams can both trust.
03 · Research & discovery
An audit of the whole portfolio
I began with a structured audit of the portfolio, capturing every brand's identity, the UI each team had already built, and how each brand renders across breakpoints, typography, layout, and components.
04 · Defining the problem
Reframing the brief
Synthesizing the research, the problem reframed itself.
How might we build one design system every IHG brand can share, without flattening what makes each brand distinct?
The reframe: brand identity isn't a set of components, it's a set of values applied to shared components. So the system's job wasn't to design 28 brands, it was to design one structure and a reliable way to re-skin it.
To make that scalable, I broke the portfolio into three brand categories, each a tier with a shared design register.
Luxury
e.g. Regent
Premium
e.g. voco
Mainstream
e.g. Holiday Inn
05 · The solution
A token-driven foundation
The foundations are codified as layered design tokens, visual standards turned into reusable infrastructure, so brand identity resolves through the token layer rather than through forked code.
Layer 1
Base tokens
The raw, brand-agnostic primitives, every color, size, and space value the system can draw from.
Layer 2
Alias tokens
A named, intent-based layer, semantic roles like text-primary or button-primary that components reference.
Layer 3
Brand themes
Each brand is a theme: a mapping that points the alias tokens at specific values.
Layer 4
Category baselines
Luxury, Premium, and Mainstream sit in the middle, providing shared theme baselines each brand refines.
06 · The results
One component, many brands
One component, one set of token references, and as many brands as there are themes. A button is built once, Regent's button and Holiday Inn's button are the same component resolving different theme values.
~28
hotel brands on one shared system
1
component library, themed per brand
Two luxury brands on one shared structure, the same hero, booking bar, and feature components resolving distinct theme values, Regent's teal and serifs versus InterContinental's warm gold.
07 · Shipped
The system in production
Regent Santa Monica, built entirely from the shared component library on the luxury theme. Every screen here uses the same components other IHG brands run, resolving Regent's tokens: its serif display type, palette, and spacing.
A different tier from the same system: Holiday Inn Express on the mainstream theme, one page resolving cleanly from desktop to mobile.
Want the full walkthrough?
Happy to walk through the token architecture, the governance model, and how new brands onboard.