Building design systems that teams actually use across fragmented multi-product platforms

Three companies over five years. Three broken design environments. The specifics were different each time and the root cause was always the same: designers building in isolation, engineers implementing what was in front of them, no shared system making consistency automatic. Building the system was the straightforward part. Getting teams to actually use it was not.

Chapter 01: Quincus

When I joined, four designers across four teams were working in Adobe XD with no shared component library. Each designer maintained their own file structure. Components were duplicated across files. Patterns diverged over time. Engineering handoff was manual and inconsistent.

The question was whether to build a shared system in XD or migrate to Figma. A shared XD library was the lower-disruption path. It avoided migration cost and let teams keep working in familiar tools.

The problem: Figma's shared library model was built for the kind of multi-team collaboration we needed. XD's was not. Building a system in the wrong tool would work until it did not, and then require a migration anyway.

I moved the entire team to Figma and built a full component library from scratch. The migration cost was real: two weeks of disruption while designers rebuilt working files. The long-term gain was a library model that actually enforced consistency rather than just suggested it.

The shift that mattered was not the tool change. It was creating a working norm where designers pulled from shared patterns rather than creating their own every time.

Chapter 02: PropertyGuru

PropertyGuru For Business provides data and consultancy services to banks, valuers, property developers, and agents across four Southeast Asian markets: Singapore, Malaysia, Thailand, and Vietnam. I built a design system from scratch to serve multiple products across all four markets.

What works in Singapore's mature property market does not automatically translate to Vietnam's rapidly growing one. The system had to be flexible enough to accommodate real market differences without fracturing into four separate systems. One system serving four contexts, or four systems that happen to share components: that was the structural question underneath every design decision.

I chose to involve engineering from the start, before a single component was designed. Every design system I had seen fail up to that point failed the same way: engineers received it rather than built it. I ran cross-functional workshops early to surface technical constraints and give engineering teams ownership over decisions that affected their work. This slowed the early design phase. The tradeoff: when the system launched, engineering teams had already resolved their objections. Adoption happened without the resistance that kills most design systems in the first six months.

Three adoption decisions that held: engineering involvement from day one so teams built the system rather than received it; connecting adoption to outcomes leadership tracked; and training that was ongoing rather than a one-time handoff.

Chapter 03: Kore.ai

Joined to find multiple teams with separate component sets, no tokens, and no design review process. Built a coded design system with live tokens. Created a component gallery documenting every shared pattern. Established structured design reviews.

Then the product shifted to vibe coding and engineers began generating UI directly from AI prompts.

The question was whether to maintain Figma-based design system workflows or transform the system to work inside AI-assisted development. Staying with Figma-based workflows was the path of least disruption. It was also a path toward irrelevance: if engineers were generating UI from prompts, a design system that lived in Figma was increasingly disconnected from how the product was actually being built.

Tokens moved from Figma to code. The component gallery replaced Figma as the team's reference layer. Design standards were embedded in AI coding tools so that engineers generating UI were working within the system rather than around it. The design system became enforcement infrastructure. That is a different thing from a component library, and building it required treating design standards as code artifacts rather than design artifacts.

What I would do differently

At PropertyGuru, the metrics I tracked were output metrics: delivery time, feature velocity, satisfaction scores. I did not track what I should have measured earlier: how often engineers actually referenced the system when making decisions. Adoption is not the same as compliance. Teams can pass design review and still not use the system as a working reference.

Running this again, I would add a lightweight usage signal from the start: a simple way to measure whether teams are pulling from the library or rebuilding components independently. That signal would have shown me where adoption was thin months before the output metrics did.