Bupa Design SystemCase Study
Design Once Ship Everywhere.
Design token architecture and automated governance across three brands and three platforms at Bupa Australia.
Nate Mills
Design token architecture and automated governance across three brands and three platforms at Bupa Australia.
Nate Mills
Engaged through Torii Consulting for a six-month independent audit of Bupa Australia's design system. Three brands (Bupa, Blua, Mindplace), five Figma libraries, web and native platforms.
I came in as an outside expert: assess the system against industry standards, identify the debt that was costing the team, and lay out a roadmap. Then build the architecture, governance, and automation to deliver on it.
Token architecture, contribution governance, and the Power Automate intake pipeline. All built to be owned by the team after my engagement ended.
Design systems accumulate debt. Stripping it back is half the job.
The other half is the governance and automation that stop it coming back.
Initial scoping suggested 43 Figma libraries. The audit found 131 across 8 workspaces. Around 80 working files had been accidentally published as libraries. Archived libraries still showed 100+ weekly inserts. Teams had independently created and published libraries to solve immediate needs.
There was no foundation team, no single source of truth, no intake process, and no formal contribution path. The question “who decides?” produced a different answer depending on which team you asked.
Teams shipped fast. Governance came later. Organic drift was inevitable.
Nobody did anything wrong, everyone solved their own problem.
Duplicate components
The same primary button lived in four libraries, each subtly different. Designers could not tell which was canonical.
Zombie libraries still in active use
Deprecated libraries were still referenced by production files. Retiring them without a plan would break live pages.
Cross-platform mismatch
Web and native used different names for the same token. A design signed off in Figma shipped looking different on iOS.
Working files mixed with published libraries
No separation between draft and source of truth. Unfinished work was being consumed as if it were canonical.
Naming drift across platforms
cool-grey, coolgrey, and coolGrey all existed. Build tools treated them as different tokens.
Orphaned styles with no owner
Legacy styles sat on the shelf with no roadmap and no one accountable for them.
No deprecation path
Teams did not know what was safe to delete, so nothing was deleted.
Undocumented design decisions
Rationale lived in Teams chats, or nowhere. New contributors kept rehashing the same debates.
No contribution model
Requests came in through eight different channels. Nothing was trackable or triaged.
The token audit uncovered structural issues that would block any migration attempt. These were ranked by severity: critical issues would cause silent UI failures if not resolved first.
Alpha scale naming collision
Legacy tokens used a 0-100 scale where alpha-100 meant solid. The new system used 0-1000 where alpha-100 meant 10% transparent. A direct name migration would make UI elements invisible with no error.
Incompatible alpha scales
Web defined 7 transparency stops per colour (100% efficient). Native defined 21 stops (only 62% referenced). A 1:1 cross-platform mapping was impossible.
Naming inconsistencies causing silent failures
cool-grey vs coolgrey vs coolGrey. Build tools treated these as different tokens. Scripts failed silently when names didn't match.
Token collection name typos
Spelling inconsistencies in collection names persisted across multiple files. Migration scripts could not find their source files. No review process existed for token file structure.
244 coloured alpha tokens
Across native and web (4 colours x 20+ stops, multiplied across brands). A single black + white overlay approach could replace all of them.
I also assessed the token files against the W3C Design Token Community Group (DTCG) specification, identifying gaps in naming conventions and file structure that would need to be addressed for interoperability with tools like Style Dictionary or Tokens Studio.
Colour contrast and accessibility were considered throughout. The token consolidation prioritised maintaining WCAG AA compliant pairings across all semantic surface and text combinations, ensuring the unified system would not introduce accessibility regressions.
I built a “Rosetta Stone” mapping to reconcile every token name and value across web and native. The unified semantic layer was platform-agnostic, with platform-specific output only at the primitive translation layer. 1,714 tokens became 450: 235 primitives and 215 semantics. Alpha tokens dropped from 415 to 22, a 95% reduction. Of the 244 coloured alpha tokens identified, 205 were eliminated and the remainder were consolidated into a single black/white overlay system.
149 tokens that had previously existed only in code (typography, dimensions, component tokens) were added to Figma Variables for the first time. Designers and developers could finally reference the same canonical source.
The single source of truth was delivered in three formats: an editable Excel spreadsheet for stakeholder review, Figma Variables for the design team, and W3C DTCG-compliant JSON for the Style Dictionary build pipeline. Each format served a different audience but drew from the same canonical data.
Multi-brand consolidation brought Bupa, Blua, and Mindplace under one architecture, with brand-specific theming handled through modes rather than separate token files. Five grey scales became two. Twenty-seven colour families were rationalised to thirteen.
450 tokens total, split across the three tiers. Primitives are the raw values. Semantics are the named aliases. Components inherit both.
Every colour family uses a consistent 11-stop scale (50-950). Real hex values from the consolidated token system.
Hand-off needed an honest scorecard, not a victory lap. Working with the design and engineering leads, I walked the team through thirteen foundational decisions and recommended a status for each: locked and ready to ship, parked for governance to resolve, or open to refine through real use. The foundation is solid. Some decisions are deliberately unfinished, because the team will sharpen them better than I can on my own.
Before my engagement, the team had no central intake form. Requests arrived from eight scattered channels: Teams DMs, Figma comments, Confluence pages, hallway conversations, phone calls, and meeting action items. Nothing was tracked. Nothing was triaged.
I designed a contribution framework around a five-step process: Need, Submit (one form, two minutes), Triage (Light/Medium/Heavy), Route (right team, right level), Done (clear owner, clear next step).
Light governance that enables speed. Too little creates chaos. Too much kills adoption.
We're not gatekeepers, we're a service.
Each request was categorised into one of three triage tiers, which determined SLA, ownership, and approval level. Representative sample of 12 governance patterns from the full framework.
This roadmap plots the design system's progression across three core capabilities, from manual foundations through automation to an aspirational dream state.
Excerpt from the full maturity roadmap.
The complete version in the governance report covers the full capability set across the design system lifecycle.
Requests didn't stop coming in from everywhere. They never will. What changed is that there's finally a place to direct them, and an automated flow behind it that catches what used to slip through the cracks.
Requests came from everywhere: DMs, channels, hallway chats, Figma comments, calls. There was nowhere to direct them.
Each one was captured manually by whoever happened to catch it. No form, no triage, no consistency. Things slipped through the cracks.
One intake form, one process. Every request flows through the intake form, automatically routed, fanned out to the surfaces the team already lives in, and tracked end to end with SLA visibility and clear ownership.
The flow tree below shows the actual Power Automate structure: 31 actions, 14 variables, 6 connectors, and a Switch block handling four urgency tiers.
A single cloud flow triggered by Microsoft Forms. It initialises 14 variables, runs an urgency Switch, loops through links and attachments, creates an ADO work item, logs the request to a SharePoint list, posts a Teams Adaptive Card, and sends two formatted emails, all in one run.
A single Power Automate flow handles conditional routing, variable manipulation, and parallel branches. Every submission fans out across the four surfaces the team already lives in. Each tab below shows the actual output.
Four spokes feed the SharePoint hub. The hub feeds a single Power BI dashboard. The dashboard is the visible output, but the capability itself lives in the schema and the flow graph.
A single Power BI dashboard fed by the Figma Library Analytics API, webhook logs, and SharePoint data. Replaces three separate cards with one consolidated view.
Illustrative dashboard layout. Sample data shown, not live metrics.
Six months of consolidation, governance design, and automation produced measurable structural improvements across the system.
Everything was delivered within the contract period and transferred to the team. I recommended a phased rollout rather than a big-bang migration for the remaining component re-tokenisation. The semantic tokens were designed to be platform-agnostic with platform-specific transforms at the output layer, meaning brand expansion becomes a configuration change, not a rebuild.
Seven structural problems surfaced by the audit: duplicated libraries, naming conflicts, colour family and scale fragmentation, neutrals sprawl, alpha token bloat, and a stalled Figma Variables migration. Each became a workstream in the roadmap.
Beyond the token architecture and governance framework, I produced a comprehensive set of artefacts built to outlast the engagement.
Editable master with all 450 tokens, mappings, and migration notes.
Style Dictionary-ready JSON. Direct pipeline to code.
Full analysis of all 1,714 tokens with cross-platform comparison.
Browsable colour families, scales, and alpha variants with live swatches and token metadata.
WCAG AA/AAA pass-fail testing across every foreground-background pair in the token set.
Every token inconsistency captured as a tracked work item with platform tag, severity, and owner.
Contribution model, triage framework, and maturity roadmap.
Conditional routing, variable manipulation, and parallel branches powering the intake infrastructure.
Governance infrastructure should be set up so any team member can run it. Every automated flow, every service account, every shared channel was configured with team continuity in mind. The intake pipeline runs whether I am there or not.
Not everything needs to be resolved before V1 ships. The 7-3-3 framework (7 locked, 3 deferred, 3 evolving) gave stakeholders confidence that the foundation was solid while acknowledging that some decisions need real-world validation before they can be finalised.
The token consolidation also highlighted the value of building accessibility into the foundation layer. WCAG AA contrast compliance was verified across all semantic surface and text token pairings.
The Figma Enterprise API webhook integration would be a strong next step. Automated library creation monitoring would help prevent sprawl recurring during a consolidation period.
Investing more time upfront on shared vocabulary with the native development team would also accelerate naming reconciliation. Earlier alignment on semantic conventions reduces handoff overhead later.