Multi-brand design system engine – Cisco

Role

Architect & lead engineer

Team

2 engineers & 2 designers

Company

Cisco

Overview

Cisco is one of the most acquisitive companies in the technology industry, regularly integrating new brands into its product ecosystem. Each acquisition brings its own visual identity, and fully transitioning a company onto Cisco’s design system can take anywhere from several months to several years. During that window, products look and feel fractured, undermining the user experience and diluting brand trust across the portfolio.

When Cisco began overhauling its design system, we saw an opportunity to build something more scalable from the start rather than carry the same structural problems into a new system. I led the architecture and engineering of a multi-brand design system built to absorb that complexity: a token-based theming engine that allows any acquired brand to maintain its own visual identity while inheriting Cisco’s full design system foundation from day one.

Problem statement

Before this system existed, dozens of teams across Cisco were maintaining their own tokens and components independently. There was no single source of truth. When Cisco made major brand decisions, like updating core brand colors, propagating those changes across the organization took years. Many projects had changed ownership so many times that the design team didn’t always know who to contact to request an update, let alone coordinate one.

Every acquisition made this harder. Companies like Duo, Meraki, and Splunk each had established brand languages their users recognized and trusted. Forcing an immediate migration to Cisco’s design language was disruptive, slow, and organizationally contentious. Leaving each brand to manage its own component library in isolation only deepened the existing maintenance problem.

The system needed to hold both realities at once: rigorous enough to scale across a large enterprise, flexible enough to respect brand diversity without fragmenting ownership.

Solution

The system is built on a layered token inheritance model. At its foundation are two base themes, Magnetic (dark and light) and Magnetic Classic (dark and light), which define the complete design token schema: color roles, elevation, typography, spacing, and interaction states. Brand themes for Cisco, Duo, Meraki, and Splunk inherit this entire schema and only specify tokens that differ from the base. Onboarding a new brand means defining a focused set of overrides rather than rebuilding a token architecture from scratch.

Theming inheritance

Automated Token Pipeline

To keep Figma and code in sync, I designed an automated token propagation pipeline using a custom token engine and Style Dictionary. When a design token is updated in Figma, the engine processes that change and automatically generates platform-specific output, publishing across 8 themes, 4 brands, and 6 formats: CSS, Sass, Less, XML, Android, and iOS. What previously required manual coordination across design and engineering became a single, auditable pipeline. A brand color update that once took years now propagates in minutes.

Flexible Consumption Model

One of the practical challenges was that teams across Cisco had varying levels of engineering resources and different tolerances for how updates were received. To accommodate this, the system supports two consumption paths. Teams can pull tokens via CDN, which means they receive updates automatically with zero engineering overhead. Teams that need more control over their release cycle can consume versioned packages instead, giving them time to QA changes before they go live. Package updates reduced per-cycle engineering time by 3 hours per team. For teams on the CDN path, that overhead is eliminated entirely.

To ensure adoption wasn’t blocked by existing technology choices, the system was built to support every style format in active use across the company: CSS, Sass, Less, XML, Android, and iOS.

Demo

Impact

The system is actively used across 4 brands: Cisco, Duo, Meraki, and Splunk. What was previously a years-long process to propagate a brand color update now takes minutes. Dozens of teams that were independently maintaining their own tokens and components now have a single source of truth to work from. Onboarding an acquired brand went from a months-long migration effort to a matter of weeks, and teams no longer need to negotiate visual standards from scratch each time.

Reflection

This project reinforced that good design infrastructure has to reflect how teams actually work. The architecture holds up because it was built around a real understanding of where teams needed flexibility and where shared constraints genuinely served them. Getting there required as much facilitation as engineering, and that balance is something I want to keep developing at a higher level of depth and rigor.