Radical Rationalization at Western Union

The Numbers

40 markets unified under one system. 146 components consolidated to 10 atomic generators, a 93% reduction. A 3-tier token architecture (reference, system, component). One source of truth across web, app, and retail POS.

Challenge

Western Union operates in roughly 40 markets across web, mobile app, and retail point-of-sale. Over a decade, the design system had grown organically to 146 disconnected components. Each market maintained its own forks. Each product had its own theme. Engineers copy-pasted and diverged whenever the system got in their way. Every release required manual reconciliation across regions, a tax that compounded with every new market, every new product surface, every quarterly cycle.

The problem was not bad design. The problem was no architecture. Components had been built bottom-up, one-off, in response to immediate needs. Nobody had ever drawn the dependency graph.

Discovery: The Inventory

The first artifact I produced was not a roadmap. It was an inventory.

I catalogued all 146 components by hand over three weeks: every fork, every divergence, every silent override that a local team had introduced without documentation. I drew the dependency graph on a wall. What emerged was not chaos. It was a pattern.

93% of the variations could be traced back to 10 atomic generators. The remaining 7% was noise: dead components, one-off experiments, abandoned prototypes that nobody had deleted.

“

Stop thinking in components. Start thinking in generators. A component is what you see. A generator is what produces it. Consolidate at the generator layer and the components collapse on their own.

”

The generator concept is what makes the reduction from 146 to 10 possible without losing expressiveness. A generator is a parametric primitive: a set of constraints (spacing, colour, typography, interaction) that can produce a family of components. A button generator, for example, produces primary buttons, secondary buttons, ghost buttons, icon buttons, loading buttons. They are all one thing with different configuration. They were never separate components. They were separate instances of a single decision.

Strategy: Tokens First, Components Second

The conventional approach would have been to redesign the component library. We did the opposite.

We unified the token layer first, starting with colour and spacing. Then typography. Then the motion scale. Only after the token layer was stable did we touch the components. By then, most of the decisions had already been made one level down.

Token Architecture (W3C DTCG compliant)

Reference tokens are raw palette values. Brand yellow, grey scale, blue scale. They are platform-agnostic and never consumed directly by components.

System tokens are semantic aliases. surface.primary, text.secondary, border.default. These are what components actually consume. They carry intent, not colour values. When a component says “use surface.primary”, it does not know or care whether that resolves to white, cream, or dark grey.

Component tokens are specific overrides. button.primary.background, field.border.focus. They are sparse by design. Most components inherit everything from the system layer. Component tokens exist only when a component needs to deviate from the system default for a justified reason.

This architecture means that dark mode is not a feature built into components. It is a configuration concern: a single JSON file that remaps surface.primary from white to grey.95, text.primary from black to white, and so on. The component code is identical in both modes. No conditional logic, no isDarkMode flags, no duplicated style blocks. The same principle applies to multi-brand: a new brand is a new token override file, not a new component library.

Why this order matters

Most teams start with components because they are visible. You can show a redesigned button in a sprint review. But a button redesign without a token architecture underneath it is a cosmetic change. The next time someone needs a new brand or a new theme, they fork the button again, and you are back where you started.

Starting with tokens is harder to explain, slower to show progress, and politically thankless. But it means that every component you build on top inherits the architecture for free. You make the decision once, at the token layer, and it propagates everywhere.

Governance: Federated, Not Central

Forty markets means forty local teams, each with regional ownership, legal constraints, and product timelines. A centralized governance committee would have been rejected within a quarter.

Instead, we built a federated model:

The core team owns the generators (the 10 atomic components) and the token architecture. Any change to a generator or a system token goes through the core team.

Local teams own their market themes and can propose extensions. A market that needs a specific regulatory disclaimer component does not ask permission. It builds it locally, following the token architecture, and proposes it upstream if other markets could benefit.

Proposals flow up, reviews flow down. Local teams submit proposals. The core team reviews for architectural consistency. Approved proposals either become core generators or remain local extensions with documentation.

Quarterly audits keep the loop honest. Every market’s deviation from core is measured. Deviations are either justified (regulatory, cultural, product-specific) or reconciled (brought back into alignment). The audit is not punitive. It is a calibration mechanism.

“

Design systems are political before they are technical. The framework has to be adopted, not imposed. If a local team feels ownership, they maintain quality. If they feel controlled, they fork.

”

The cultural shift was harder than the technical one. Engineers who had spent years maintaining their own forks were not going to give them up because a slide deck said they should. The adoption strategy was based on demonstration, not mandate: pick one market, consolidate it to the new architecture, measure the results, then let those results do the selling.

The Build Pipeline

The token architecture feeds a single-source build pipeline:

W3C DTCG token format is the source of truth. All tokens live in JSON files following the industry-standard structure. Human-readable, machine-parseable, version-controlled.

Style Dictionary transforms those JSON tokens into every platform output the system needs: CSS custom properties for web, SCSS variables for legacy surfaces, TypeScript constants for React, Swift values for iOS, Kotlin values for Android. One source, multiple outputs. When a token changes in the JSON, every platform picks it up on the next build.

Figma Variables are synced via API. Designers work with the same tokens that engineers consume. There is no translation step, no “design specs” that an engineer interprets. The Figma file and the codebase read from the same token set.

This pipeline eliminates an entire category of bugs: the “design says one thing, code says another” problem. When the source is shared, the drift is zero by construction.

The Framework: Radical Rationalization

This work crystallized into a repeatable framework that applies beyond Western Union:

Step 1: Inventory. Catalogue everything. Every fork, every override, every silent divergence. You cannot rationalize what you have not measured. Most teams skip this step because it is tedious and the findings are uncomfortable. That is precisely why it matters.

Step 2: Find the generators. Behind the variation, there are patterns. Identify the atomic producers that, with the right parameters, can generate the full range of variation you need. This is the intellectual leap that makes the 93% reduction possible.

Step 3: Consolidate at the token layer. Do not redesign components. Redesign the decisions underneath them. Build the 3-tier token architecture first. Components inherit correctness from the architecture.

Step 4: Federate governance. Central ownership of architecture. Distributed ownership of expression. Core team reviews, local teams propose. Nobody loses autonomy over their market. Everyone gains consistency.

Step 5: Audit quarterly. Systems drift. Teams cut corners under deadline pressure. Measurement prevents entropy. The audit is not about compliance. It is about keeping the architecture honest.

“

Most design system bloat is not a component problem. It is a decision architecture problem. Fix the decisions, and the components fix themselves.

”

Key Results

93% component reduction: from 146 disconnected components to 10 atomic generators.

Single token source of truth consumed by web, mobile, and retail across all 40 markets.

Dark mode achieved through token configuration, not component rewrites. Zero conditional logic in component code.

40 markets operating under federated governance with quarterly audit cadence. Deviations measured, justified, or reconciled every quarter.

Build pipeline generates platform-specific outputs (CSS, SCSS, TypeScript, Swift, Kotlin) from one JSON source. One change propagates to every platform on the next build.

What I Learned

On architecture: The token layer is the real product. Components are just the visible expression. If you get the tokens right, the components almost build themselves.

On governance: Federated beats centralized every time at scale. Central governance works until the second team disagrees. Federated governance works because disagreement is built into the process.

On adoption: Demonstrate, do not mandate. One migrated market with measurable results convinces more people than a hundred presentations.

On measurement: If you do not measure deviation, you cannot prevent entropy. Systems do not stay consistent by default. They stay consistent because someone checks.