Building a scalable design system for a global risk platform

Context

A product family with no shared design language

A risk and compliance team at a global pharmaceutical company was working across a family of internal products covering different functions. UI varied depending on who built it, handoffs to engineering were messy, and prototyping took longer than it should. The team wanted faster prototyping and consistency across the family. Dataviz was a core part of how every product communicated information, so it had to be part of any system worth its name.

A Figma design system usually covers UI primitives, colour, typography, and components. Dataviz tends to sit outside it, owned by an engineer or assembled per project. For this team that wouldn't have worked, because dataviz was central to every product they shipped, and a system that didn't include it would have left the biggest source of inconsistency untouched. So I made the call early that dataviz had to be inside the system, treated as a subsystem of its own.

The audit

Inconsistencies, accessibility gaps, and a brand hub already in place

Four weeks, atomic methodology, sign-offs throughout. A full audit of the existing Figma files covered UI, palette, dataviz, and typography. The team had an existing brand hub, the result of years of brand investment across the organisation. We cross-referenced against it throughout the audit and built the system to align with it rather than replace it, so it could be adopted without setting up a second source of truth alongside the brand work the organisation had already invested in.

During the audit we found UI colours that weren't passing accessibility checks, so we swept the full palette, optimised, and shipped corrected colours into the system foundation. Audits like this often surface accessibility gaps, and there's a choice about where to fix them. We fixed ours into the system foundation rather than handing them off as a recommendation, which meant every product built on the system from that point inherited the corrected palette automatically. Catching it once in the system was the cheapest place to catch it, and it meant the team didn't have to retrofit individual products later.

Components, states, layouts, and documentation followed, with Dev Mode configured so engineers could pull tokens directly from Figma. I collaborated closely with the dataviz designer from a partner agency throughout.

The dataviz subsystem

Dataviz isn't usually part of a Figma design system, but here it needed to be

It was central to every product in the family, and data-visualisation components aren't typically something you can build inside Figma. We embedded a paid Figma plugin into the workflow and treated dataviz as its own subsystem alongside the atomic components, with styling, documentation, and worked examples. The team could prototype real charts in Figma the same way they prototyped any other UI, and that was the piece that genuinely unlocked the prototyping speed they'd asked for.

Outcome

A system the team built new products on top of

The design system stayed in active use across the rest of the 6-month engagement, with new products and services designed on top of it while components were maintained in parallel. A design system's test is whether the team keeps using it once the person who built it isn't there day-to-day. I built to that bar by treating documentation and Dev Mode tokens as first-class deliverables alongside the components themselves.