Beyond Aesthetics: Why “Design Tokens” Are the Unsung Heroes of M&A Engineering

When people hear “design system”, they tend to picture a style guide, a document somewhere telling designers which blue to use. That’s a fair mental model for a ten-person startup. It’s a dangerously incomplete one for a global enterprise that has spent a decade acquiring companies across multiple countries, each with its own frontend stack, its own component library, and its own idea of what a button should look like.

That’s the view of engineering lead Sandeep Mauriya, who has spent much of the last two years inside exactly that problem, first helping unify the front-end architecture across a shareholder-services company’s international product lineup and more recently working on semantic design token migration across large-scale financial services platforms, including shareholder services, digital banking, and wealth management applications.

“When a company acquires five businesses in five countries, what they’ve actually acquired is five different codebases pretending to be one brand,” Mauriya explains. “The logo might be consistent. Nothing underneath it is.”

This is the part of post-acquisition integration that rarely makes it into the boardroom slide deck because it doesn’t sound strategic; it sounds like a frontend chore. But the cost of frontend fragmentation compounds fast. Every acquired product team maintains its own colour values, its own spacing rules, and its own component logic. A single brand refresh – something as simple as adjusting a primary colour for accessibility compliance – has to be manually reimplemented across every product, in every codebase, by every team, with no guarantee of consistency at the end. Multiply that across dozens of components and multiple platforms, and an engineering organisation is quietly bleeding hours into work that produces zero new customer value.

Design tokens solve this by treating design decisions as data rather than as scattered hard-coded values. Instead of a developer writing a colour value directly into a stylesheet, that value lives once, in a single source of truth, referenced everywhere through a semantic name, such as core.action.primary.default, that describes its role rather than its raw value. Change the token once, and every button, every chart, every alert across every acquired product updates automatically, in both light and dark mode, without a single engineer manually touching downstream code.

“A design token isn’t a colour. It’s a decision that only has to be made once” is a phrase Mauriya uses often when explaining this to engineering leads who are sceptical about investing time in what looks like design tooling rather than “real” engineering. In practice, it’s some of the highest-leverage engineering work a large organisation can fund, because it collapses what would otherwise be dozens of parallel, error-prone manual updates into a single automated propagation.

The tooling side of this has matured considerably. Working across Figma Tokens, Storybook, and Zeroheight, engineering teams have built pipelines where a designer’s decision in Figma flows automatically into a JSON token file, which in turn drives the actual component code, with visual regression testing catching any unintended drift before it reaches production. This closes a gap that used to be a permanent source of friction between design and engineering teams: the gap between what a designer intended and what actually shipped. 

Beyond the visual consistency argument, there’s a harder-edged business case. In similar design system programmes, standardising reusable components across product squads has measurably reduced duplicated engineering effort, in one case by roughly a third, simply because teams stopped rebuilding the same button, modal, and card components from scratch for every product line. “That’s not a design win,” Mauriya says. “That’s an engineering budget win, and it’s one that compounds every quarter the system stays in place.” 

“The strongest argument for a design system was never ‘it’ll look nicer’,” he tells CFOs evaluating whether to fund this kind of work. “It’s ‘we’ll stop paying five engineering teams to solve the same problem five times.'”

There’s also a quieter benefit that matters enormously in regulated industries: accessibility compliance becomes centralised rather than aspirational. When colour contrast ratios, focus states, and interaction patterns are baked into tokens rather than left to individual developer discretion, meeting standards like WCAG 2.1 stops being a per-product audit exercise and becomes a property of the system itself.

None of this makes design tokens a silver bullet. They require genuine cross-functional buy-in; design, engineering, and product all need to treat the token layer as shared infrastructure, not as one team’s side project. Monorepo architecture, CI/CD integration, and disciplined governance over who can add or modify a token all matter as much as the tooling itself.

But for any organisation navigating the aftermath of acquisitions, or simply trying to scale a product across multiple platforms without fragmenting its brand and its engineering effort in the process, design tokens deserve a seat at the strategic table, not a spot tucked away as a design team concern. “They are, in the most literal sense,” he says, “the infrastructure that lets a company actually behave like one company. Organisations that invest in semantic design tokens, shared component architecture, and governed design systems are better positioned to integrate acquisitions, scale digital products across platforms, and deliver consistent customer experiences at enterprise scale.”