One design system for 100+ brands

100+ brands take their look from one design system. It replaced the separate systems at Expedia, Hotels.com, Vrbo and on the partner side.

Role
Senior Design Systems Designer, Expedia Group Design System, having moved across from Hotels.com
What I owned
Cross-platform layout foundations, token synchronisation pipelines across the platform repositories, theme-based component frameworks serving 100+ brands, and maintaining the governance and contribution models
What the team owned
A design system community working in squads grouped by component family, across offices in Seattle, Brisbane, Gurgaon and London
Duration
2021 to 2023, within a programme that ran to 2026

The problem

Four systems, four answers to every question, and no way to borrow one.

Expedia Group ran four separate design systems, one each for Expedia, Hotels.com, Vrbo and the partner and supply side. Each had its own date picker, its own search field and its own interpretation of what accessible meant, and each team was solving those problems from the beginning while the others did the same.

The reorganisation gave the reason the company acted, which was duplication and cost, but that is not the reason the work was hard. The difficulty was that all four answers were defensible. A date picker built for Vrbo was not a worse one, it was built for a brand renting whole homes by the week rather than rooms by the night, and treating that difference as waste would have produced a component that suited nobody.

One library had to carry the differences that mattered, and refuse the ones that were only accidents.

How the merge was decided

Five ways to converge, a recommendation the business overruled, and a rebuild abandoned halfway.

The design system leads worked up five convergence scenarios, from keeping the four systems independent on shared foundational tokens through to a single enterprise system with the organisation re-platformed onto it. We recommended one of the middle options and the business chose the most ambitious, which set the constraint everything afterwards was solving for: replatforming an organisation on a schedule that assumed a rebuild nobody had proved was possible.

The mechanism that made it survivable was a three-tier token architecture. Foundation tokens hold the raw values, semantic tokens carry meaning rather than appearance, and feature tokens sit at component level. A brand differentiates itself by overriding tokens rather than rewriting components, which let one library render as 100+ brands without a fork for any of them.

My own work sat underneath that. I ran the pipelines keeping token values in step across the platform repositories, because the architecture is only worth having if Figma, iOS, Android and web agree on the current values, and four repositories drifting apart would have reproduced the original problem one layer down. I defined the layout foundations too, the spacing and structural standards that had to mean the same thing everywhere.

Bringing a component onto the platform was called graduating it, and the bar was high: WCAG 2.2 with automated tests, theming through feature tokens, parity across Figma, iOS, Android and web, dark mode, localisation, and scaling to 320px. Fifty-five cleared it.

Directions we did not take

The largest of these was made after the work had already started.

  1. Read from the EGDS foundation files rather than sampled. Ten values differ across the three brands; the type scale, radius, spacing and sizing are identical in all of them.

    Building all four design languages into every component

    Abandoned partway through. The original plan built each brand’s identity into the components themselves, so no brand would need a redesign to adopt the system, and it was why the ambitious scenario looked survivable at all. It proved far more complex than the early assessment suggested, because every component carried four sets of decisions and every later change had to be correct in four places at once. We pivoted to Expedia’s UDS component as the base with brand tokens on top, which cost some fidelity and bought a system that could ship.

  2. The middle convergence scenario we recommended

    The business rejected it. We had not. The trade-off it offered is the one the programme had to make anyway. It kept the four systems independent on a shared token foundation, slower to show a single library and far cheaper to reverse. Full re-platforming made the abandonment above a mid-flight correction rather than something we could walk away from.

    1. Team tier
      CoreShared
      TeamTeamTest
    2. Shared tier
      CoreSharedPromote
      TeamTeam
    3. Core tier
      CoreMergeShared
      TeamTeam

    Letting any team promote a component into the core

    Rejected while I was building the contribution model. The generous version lets a team push a component straight into the shared library, which is the fastest way to get contribution and the fastest way to fill a core library with components only one team can maintain. What shipped puts acceptance criteria and RICE ranking in the way, and accepts that most components never make the journey.

What shipped

One component library, themed per brand through tokens, with a governance model deciding what could join it.

Resolve the feature layer for a brand
Pick a brand: it sets its own raw values and the component is untouched, which is why the button is the same blue in all three. Values read from the EGDS foundation files.

Governance was three tiers and mattered as much as the components. A team could build on EGDS foundations in its own workspace at the team tier. Teams working on similar problems promoted components to a shared tier and developed them together. Only components meeting the acceptance criteria and surviving RICE ranking reached core and took on full system maintenance.

Few components ever finished that climb. A component at the shared tier, with three teams on it, showed three teams solving the same problem. Four separate systems never showed that.

Impact

These figures count how widely the system was taken up.

55
components graduated to the full bar for accessibility, theming, platform parity and dark mode
1,000+
designers and engineers working in the system across the organisation
100+
brands and white-label partners themed from one shared token foundation

Programme figures, published by colleagues who worked on it, at heeranmaster.com and madebyjoe.uk. All three measure output and adoption rather than any outcome for a traveller, and no baseline was taken before the merge.

The components were built once. Each brand took its look from the shared tokens.

Accessibility went from four interpretations to one standard with automated tests behind it, and dark mode became something maintained in the token layer rather than four times over. A brand that had never shipped dark mode got it by adopting the system.

The programme measured its own adoption because that is what it set out to move.

Next