Rethinking Brand Configuration and Token Systems at Scale

As Principal UX Designer on the Expedia Group Design System (EGDS), the centralized system used across all Expedia and white label template brands, I led a cross-functional initiative to evolve how more than 100 brands configure and maintain their unique brand expressions through design tokens. Over time, our token system had grown brittle and opaque—housing over 6,000 tokens with deeply nested inheritance, poor visibility, and manual accessibility checks. These complexities resulted in high risk for anyone making changes, and a heavy maintenance burden shared across design, engineering, and product teams.

This case study outlines the systemic pain points, user needs, and strategic roadmap that informed our vision for a more resilient, flexible, and scalable brand configuration system.

Understanding our Users

The people using the token system spanned a wide range of disciplines and technical confidence. Our EGDS core team including a sub-team focused on brand design for our major three brands (Expedia, Vrbo, Hotels.com) and engineers understood the architecture deeply and needed full programmatic control. But they were the minority. Most users—product designers, account managers, engineers from partner teams—were less familiar with the system’s internals and needed guardrails and intuitive tools. Still others, including product design and engineering teams who pushed the system by building custom coded components simply wanted a stable interface with minimal friction.

The diversity of users meant that flexibility, transparency, and ease of use had to guide every decision.

Uncovering User Pain Points

We began with a series of user journey mapping sessions and interviews to deeply understand where friction occurred. It became immediately clear that the pain wasn’t isolated to any one team. Designers, engineers, and product leads all experienced varying forms of confusion, delay, and inefficiency.

Accessibility validation, for example, was mostly manual and often happened late in the process—if at all. Previewing token changes was another major blocker. Designers had no way of seeing their changes reflected in product without going through engineering or requiring designers to detach reusable components and manually test visual updates. The entry point to the token system—GitHub—required a level of technical proficiency most designers and even some developers lacked. And even once changes were made, they could take weeks to go live.

There was little clarity around who had authority to change or approve tokens. Governance was fuzzy, roles were informal, and the system’s complexity discouraged proactive improvement. Experimentation was nearly impossible, as we lacked the infrastructure to compare token sets or safely test variations. Inheritance further compounded the problem: because brands inherit from other brands and alias tokens across those lines, a single change could have mysterious downstream effects.

A recent update to our Default tokens brought many of these issues into stark relief. Rolling out even a modest change required extensive manual visualization, developer coordination across brands and apps, and ultimately introduced new technical debt due to fragile inheritance structures.

Reimagining the System

Improving the Authoring Experience

To improve the authoring experience, we piloted a new proof of concept that allowed tokens to be edited directly in Figma and synced with a centralized token API. This eliminated the need to manually edit JSON in GitHub and laid the foundation for an interface that could meet designers inside their everyday tools.

Simplifying the Token Structure

In parallel, we began simplifying the token structure itself. We proposed moving away from layered token types—foundation, semantic, feature—in favor of a UI theming model. Instead of thousands of tokens with unclear or overlapping purposes, each theme would have a defined shape and manifest. Brands could extend themes, but wouldn’t need to manage large, redundant sets.

This change dramatically reduced the total number of tokens needed and made it easier to manage ownership and deprecation. A token only existed if it was actively used in a theme, component, or brand. The system became leaner, easier to teach, and better suited for automation.

Making Accessibility and Previewing Core to the Experience

To ensure accessibility and previewing were first-class citizens, we introduced structure around token relationships. We defined a theme as more than a set of values—it became a contract, including metadata, versioning, and relationships like foreground-background contrast. Tokens were mapped directly to component needs, which allowed us to support inline previews, automated color contrast validation, and a future where components could programmatically define what they required.

Evolving Governance

Governance also evolved. We clarified who could author, review, and publish tokens. We planned interfaces that removed EGDS as a bottleneck while still enforcing constraints that would prevent inaccessible or unstable changes.

The Component Gap

As we zoomed out from tokens to the components they styled, another gap became clear. We had no shared definition for what a component was. There was no unified contract outlining what tokens styled it, how it behaved across platforms, or what variations it supported. This led to major inconsistencies.

A component like an icon might use one set of tokens on iOS, a different one on Android, and yet another on web. Banners looked constrained in Figma but accepted any content in code. Without a shared definition, platform teams attempting to initiate and configure components without having an engineer touch code couldn’t programmatically interact with our components in a trustworthy way.

Worse, token maintainers couldn’t clean up the system. Without knowing what tokens were connected to what components, or where they were used, we were left with a graveyard of unused or mysterious tokens that bloated every app’s payload. Developers had to import entire token packages just in case.

This revealed the need for structured component manifests—machine-readable definitions of which tokens a component requires, what properties they support, and how they express across brands and platforms. With these in place, both product and system teams could work more predictably and confidently.

What We Achieved

This body of work represents a foundational shift in how EGDS approaches brand configuration—not through immediate implementation, but through deep discovery, strategic alignment, and scalable planning. Rather than focusing solely on delivery, our goal was to uncover what needed to change and to define a shared path forward across design, engineering, and product.

Key directional outcomes from this effort include:

• A simplified token model that reduced total token count by nearly 90% per brand
• Pilot tooling that enabled token editing directly in Figma, synced with a centralized API
• Significant reduction in review burden, freeing up EGDS core team bandwidth
• Empowerment of non-expert users to author and manage tokens confidently
• Introduction of theme and component contracts that support scalable, accessible design across platforms

This pre-implementation alignment now informs ongoing architecture efforts and tooling investments, setting the stage for meaningful improvements across our design system.

By establishing contracts between tokens and components, between themes and brands, we paved the way for scalable, accessible, and maintainable growth across our entire design system.

Looking Ahead

This wasn’t just an architecture update—it was a cultural one. We redefined what it means to contribute to and evolve a design system at scale. By investing in clarity and simplification, we’ve created a foundation where designers, engineers, and product teams can move faster without sacrificing quality.

If we do nothing, the token system will continue to exist—but at what cost? We’re investing now so that all brands, apps, and users benefit from a future-ready foundation.