Design Once, Ship Everywhere

01

The Brief

Audit and untangle

Engaged through Torii Consulting for a six-month independent audit of Bupa Australia's design system.

Three brands (Bupa, Blua, Mindplace), five Figma libraries, three platforms (web, iOS, Android), and 1,714 design tokens that had grown faster than anyone could keep track of.

An outside set of eyes, six months on the clock. Close enough to work alongside the team, independent enough to call the system what it was.

The engagement

Six months, embedded

Sept 2025 to Mar 2026

via

Built with

Claude Code Figma Microsoft 365

Built to W3C DTCG standards Tokens authored to the W3C Design Tokens Community Group spec

My job was to see the whole picture, name what was broken, and hand back a plan. Audit the system against industry standards, define the target architecture, ship one reference automation as proof, and leave the team a backlog of epics and tickets they could own from day one.

Token architecture, contribution governance, and the Power Automate intake pipeline. All built to be owned by the team after my engagement ended.

Deliverable 01

Industry standard audit

Benchmarked Bupa's system against published patterns from IBM Carbon, Shopify Polaris, Google Material, Adobe Spectrum, Atlassian and GitHub Primer. Named the gaps honestly, prioritised the fixes.

Deliverable 02

Target token architecture

Delivered one canonical token system in three formats: Figma Variables, Excel SSoT, and W3C DTCG JSON. Designers, engineers and stakeholders drew from the same data.

Deliverable 03

Reference automation, shipped

Built an end-to-end Power Automate intake pipeline, live and tested. Microsoft Forms trigger to Teams notification to triage. Not a slide, a working system.

Deliverable 04

Owned backlog for the team

Mapped epics and tickets for each workstream, so the internal team had a clear plan to work from the day I left.

Design systems accumulate debt. Stripping it back is half the job.
The other half is the governance and automation that stop it coming back.

02

Discovery

What I found

Audit at a glance

5

Fragmented libraries

1,714

Tokens in circulation

84%

Flagged for consolidation

0

Automations in place

The audit produced fourteen ranked findings: nine across the wider design system, five inside the token files. Critical issues would break production or block any consolidation work. High-severity issues caused drift and friction, but did not break what was already shipped.

Figma Libraries Expected

Figma Libraries Found

The audit ran across four fronts: library inventory, token system structure, governance practices, and automation coverage. Libraries told the loudest story first. Initial scoping suggested 43; 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.

How they got here

Cause 01

Speed over structure

Delivery was prioritised. Governance was deferred. No design system council.

Anyone could publish a library

Cause 02

Team turnover

Institutional knowledge left with people. No documentation survived transitions.

Context lost on every rotation

Cause 03

Platform silos

Web, native, and marketing operated independently with no shared tokens.

Same name, different values

Cause 04

No single owner

No foundation team, no intake process, no formal contribution path.

“Who decides?” had no answer

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.

What I observed

Design system findings

4 Critical 5 High

Nine ranked observations spanning library sprawl, deprecated assets, cross-platform drift, and governance gaps. Scroll to advance through the cards.

4x

Duplicate primary buttons

The same primary button lived in four libraries, each subtly different. Designers could not tell which was canonical.

Sprawl

100+

Deprecated libraries still in active use

Retired libraries showed 100+ weekly inserts from production files. Pulling them without a migration plan would have broken live pages.

Risk

iOS vs Web

Cross-platform mismatch

Web and native used different names for the same token. A design signed off in Figma shipped looking different on iOS.

Drift

~80

Working files mixed with published libraries

Around 80 working files had been accidentally published as libraries. No separation between draft and source of truth, so unfinished work was consumed as if canonical.

Bloat

3x

Naming collisions across platforms

cool-grey, coolgrey, and coolGrey all existed. Build tools treated them as different tokens.

Naming

No owner

Legacy styles drifted unmaintained

Orphaned styles sat on the shelf with no roadmap and nobody accountable for cleanup.

Owner

No path

Nothing safe to delete

Teams could not tell which components were retired, so the inventory only grew. Deprecation became a guessing game.

Stale

No record

Decisions lived in Teams chats

Rationale stayed in DMs or nowhere at all. New contributors kept rehashing the same debates.

Docs

8x

No contribution model

Requests came in through eight different channels. Nothing was trackable or triaged.

Backlog

Technical blockers

Token migration blockers

2 Critical 3 High

Token files assessed against the W3C Design Token Community Group (DTCG) specification. Critical issues would cause silent UI failures if not resolved first.

0 vs 1000

Alpha scale naming collision

Legacy tokens used a 0 to 100 scale where alpha-100 meant solid. The new system used 0 to 1000 where alpha-100 meant 10% transparent. A direct name migration would make UI elements invisible with no error.

Silent fail

7 vs 21

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.

Cross-platform

3x

Naming inconsistencies causing silent failures

cool-grey vs coolgrey vs coolGrey. Build tools treated these as different tokens. Scripts failed silently when names did not match.

Build

Build risk

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.

Typos

244

Coloured alpha tokens

244 of the 415 alpha tokens carried a colour (4 colours times 20+ stops, multiplied across brands). A single black and white overlay approach could replace all of them.

Bloat

03

Tokens

One token system

The audit's findings became the brief for the architecture. The first job was to define one target the team could build toward, instead of three that kept pulling apart. The architecture is where the system is headed. Migrating the existing 1,714 references is the team's route there.

Tokens

1,714to450

Same expressive range with a 74% smaller surface. The new canonical set powers Figma Variables, the SSoT spreadsheet, and the W3C DTCG JSON downstream.

Alpha tokens

415to22

Single black-and-white overlay model replaces per-colour alpha scales.

Grey scales

5to2

Cool-grey and Warm-grey, aligned across web and native.

The new system is a single source of truth, organised in a three-tier model of 235 primitives and 215 semantics. Brand differences across Bupa, Blua, and Mindplace are handled as modes inside one library rather than as separate token files. The same canonical data flows into Figma Variables, the SSoT spreadsheet, and the W3C DTCG JSON.

W3C Design Tokens Community Group Open spec, DTCG format, multi-toolchain

View spec

Built to the W3C Design Tokens spec

Tokens authored to the W3C Design Tokens Community Group format.

Every primitive carries $value, $type and $description

Style Dictionary Tokens Studio

Tokens Studio Figma Variables

One JSON file, multiple toolchains downstream.

color.tokens.json DTCG

1{2  "color": {3    "primary": {4      "$value": "#0079C8",5      "$type": "color",6      "$description": "Primary Bupa blue"7    }8  }9}

Three-tier model

Drag the space slider from spacing.50 to spacing.400. The token name updates in the Primitive card, the Semantic alias re-points, and the button preview re-paints. Slide radius to the end for the pill.

Tier 01, Primitive 235 tokens

Raw, context-free values. The source material: hex codes, pixel measurements, unitless scales.

blue.500

#0079C8

spacing.200

16px

border-radius.100

8px

Aa

font-sizes.1125

18px

Tier 02, Semantic 215 tokens

Purpose-driven aliases. Names describe intent, not appearance; values reference primitives.

background.brand-primary

→blue.500

button.medium-padding-x

→spacing.200

button.border-radius

→border-radius.100

Aa

button.medium-font-size

→font-sizes.1125

Tier 03, Component Composed

Part-level tokens scoped to one component. Composed entirely from semantic aliases.

→

button.primary.background

background.brand-primary

→

button.primary.padding-x

button.medium-padding-x

→

button.primary.border-radius

button.border-radius

→

button.primary.font-size

button.medium-font-size

Edit primitivesCards above react in real time

blue.500 #0079C8

spacing.200 16px

border-radius.100 8px

font-sizes.1125 18px

Three tiers, each built on the last

Primitives are the raw material, the hex codes and pixel values nothing else should hardcode. Semantics name those by their job, the colour body text uses or the space inside a card. Components compose the semantics into finished parts. The semantic layer took the most work: four libraries had four names for the same thing, now one shared vocabulary.

Tier 1

Primitives

235

Raw colour, spacing, and type values. The foundational palette.

143

Colour

70

Alpha

22

Other

Tier 2

Semantics

215

Purpose-driven aliases. Named for what they do, not what they are.

156

Colour

59

Component

Inside the primitive layer

Every raw colour, type, and dimension value the rest of the system points at, 235 in total. Pick a category and hover any token to see its name and value.

Tier 1 Colour Primitives

145

Colours 99 tokens

Blue

blue-50
#F1F9FF

blue-100
#DDEDF8

blue-200
#B3D6EF

blue-300
#8DC0E8

blue-400
#51A0DC

blue-500
#0079C8

blue-600
#0652AE

blue-700
#00398A

blue-800
#0F2460

blue-900
#0D1846

blue-950
#060C22

Teal

teal-50
#E4FFFF

teal-100
#D2FBFB

teal-200
#9EF0F0

teal-300
#56DBDB

teal-400
#05B8B5

teal-500
#007D79

teal-600
#005D5D

teal-700
#004144

teal-800
#022B30

teal-900
#081A1C

teal-950
#050F10

Green

green-50
#EEFDF2

green-100
#DEFBE6

green-200
#A7F0BA

green-300
#6FDC8C

green-400
#48C06A

green-500
#1B883C

green-600
#0E6027

green-700
#044317

green-800
#022D0D

green-900
#071908

green-950
#040E04

Yellow

yellow-50
#FEFCE6

yellow-100
#FDF8CC

yellow-200
#FFF19D

yellow-300
#FEE573

yellow-400
#FED75D

yellow-500
#F1C22D

yellow-600
#BD9614

yellow-700
#6B5609

yellow-800
#453806

yellow-900
#2B2204

yellow-950
#211B03

Orange

orange-50
#FFECDE

orange-100
#FBD9C0

orange-200
#FFC097

orange-300
#F99D60

orange-400
#F97E2C

orange-500
#DB3907

orange-600
#C85204

orange-700
#9D3E00

orange-800
#702E02

orange-900
#451E11

orange-950
#251009

Red

red-50
#FFE9ED

red-100
#FED7DE

red-200
#FFACB9

red-300
#FC7188

red-400
#F04561

red-500
#D60023

red-600
#AE132C

red-700
#861E2F

red-800
#5D202A

red-900
#35191E

red-950
#1C0D10

Pink

pink-50
#FFF8FB

pink-100
#FCECF4

pink-200
#FBD3E8

pink-300
#FAA6C9

pink-400
#F26CAC

pink-500
#D02670

pink-600
#9F1853

pink-700
#740937

pink-800
#510224

pink-900
#2C0C1A

pink-950
#18070E

Purple

purple-50
#F9F7FF

purple-100
#F4F0FE

purple-200
#E8DAFF

purple-300
#D3B9FF

purple-400
#B88AF6

purple-500
#8A3FF5

purple-600
#6929C4

purple-700
#491D8B

purple-800
#31135E

purple-900
#1C0F30

purple-950
#0E0717

Skintone

skintone-50
#F6EDE4

skintone-100
#F3E7DB

skintone-200
#F7EAD0

skintone-300
#EADABA

skintone-400
#D7BD96

skintone-500
#A07E56

skintone-600
#825C43

skintone-700
#604134

skintone-800
#3A312A

skintone-900
#292420

skintone-950
#1A1714

Neutrals 22 tokens

Cool Grey

cool-grey-50
#F5F6F8

cool-grey-100
#F0F1F3

cool-grey-200
#E5E7EB

cool-grey-300
#DDE1E6

cool-grey-400
#C5CBD1

cool-grey-500
#9BA5AC

cool-grey-600
#6B717A

cool-grey-700
#4B5158

cool-grey-800
#32383F

cool-grey-900
#21272A

cool-grey-950
#121517

Warm Grey

warm-grey-50
#FCFBFA

warm-grey-100
#FAF8F6

warm-grey-200
#F7F5F2

warm-grey-300
#F1EFEB

warm-grey-400
#E5E2D8

warm-grey-500
#DCD9CB

warm-grey-600
#C6C2AF

warm-grey-700
#ABA899

warm-grey-800
#9A9787

warm-grey-900
#716E60

warm-grey-950
#484539

Alphas 22 tokens

White

alpha-0
0%

alpha-50
5%

alpha-100
10%

alpha-150
15%

alpha-200
20%

alpha-300
30%

alpha-400
40%

alpha-500
50%

alpha-600
60%

alpha-750
75%

alpha-1000
100%

Black

alpha-0
0%

alpha-50
5%

alpha-100
10%

alpha-150
15%

alpha-200
20%

alpha-300
30%

alpha-400
40%

alpha-500
50%

alpha-600
60%

alpha-750
75%

alpha-1000
100%

The alpha token decision

The hardest tradeoff was alpha tokens. The legacy system had grown to 415 of them on the assumption every primary colour needed its own opacity scale. Four colours, twenty stops, three brand variants. Unsustainable, and worse with every new hue.

28 %

Actual usage rate

Only 118 of the 415 alpha primitives were actually referenced by a semantic token. The other 72% were maintenance overhead with no real benefit. Consolidating wasn't taste, it was hygiene.

Native 24% used, 70 of 289

Neutral 48 of 168 (29%) Coloured 22 of 121 (18%)

Web 38% used, 48 of 126

Neutral 16 of 42 (38%) Coloured 32 of 84 (38%)

The decision was to consolidate. A single black and white overlay system handles every state where alpha actually appears: hover, disabled, scrim, selection. At those opacities, users do not perceive the difference.

415 22

Same expressive range. 95% fewer tokens, smaller files, faster audits, fewer naming collisions.

Scattered alpha tokens

Shared B+W stops

How it's built

Pick any base colour, swap the overlay, slide the alpha. The token name resolves in real time. Same overlay works on every brand colour.

Base colour

Alpha overlay black/alpha-200

Result

Base colour #0079C8

Overlay

Alpha 20%

V1 readiness

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.

LockedDecided and ready to implement 7

Single library structure

One source, no duplicates.

Naming conflicts resolved

Alpha scale collision fixed.

Kebab-case convention

One casing across platforms.

11-stop colour scales

Consistent ramps, all brands.

Grey palette alignment

Web and native now match.

Alpha token consolidation

415 alpha tokens consolidated to 22 shared B+W stops.

Figma migration path

Foundation for Style Dictionary export.

DeferredParked for governance input 3

Colour family naming

Needs governance consensus.

Ink token deprecation

Migration plan sits with governance.

Semantic naming conventions

Governance to ratify.

EvolvingWill refine through real use 3

Specific scale values

Refine after 3 months in production.

Semantic coverage depth

Expand as patterns mature.

Dark mode support

Needs real usage data to tune.

04

Governance

From request to owner

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. One door in, one path through, one clear owner at every stage.

01 Signal

Need raised

A team identifies a reusable problem worth bringing into the system.

02 Intake

Request submitted

The form captures enough context to assess the work without another meeting.

03 Decision

Work sized

Light, medium, or heavy is based on effort, risk, reach, and impact.

04 Ownership

Path assigned

The request lands with the team or decision-maker best placed to move it forward.

05 Outcome

Next step set

Approve, backlog, escalate, or close with a reason the requester can see.

Light governance that enables speed.
Too little creates chaos. Too much kills adoption.
We're not gatekeepers, we're a service.

Triage framework

Each request is routed into one of three tiers based on effort, risk, reach, and impact. The framework creates a lightweight path for maintenance, a review path for reusable improvements, and a governance path for strategic system change. Small fixes move quickly. Larger system changes get the right level of ownership, review and approval.

L

Light

Fast track

Same dayor next business day

Low risk maintenance where the intent is already clear and no new design decision is required.

Typical requests

Bug fixes and broken links
Token value updates
Documentation corrections

Any DS memberLow approval

M

Medium

Triage review

2 to 5 daystarget turnaround

Reusable improvements that need prioritisation, a named owner and a quick design system review before release.

Typical requests

New component variants
Pattern library additions
Usage guidance updates

DS owner assignedWeekly review

H

Heavy

Governance gate

Sprint+planned delivery

System level change with broader product, platform, accessibility or release impact.

Typical requests

New components
Architectural changes
Cross platform impacts

Design reviewStakeholder sign-off

Then who decides

Triage answers "how big is this." Decision authority answers "who signs it off." The two stack: a Light request lands at L1 with the component owner, a Heavy request climbs to L3 or L4. The point of the map is that most contributions resolve at L1 with self-serve documentation, the way a service is meant to work.

L1 Light

Component owner

1 day SLA

Bug fixes, typo corrections, single-token swaps. The component owner approves and ships, no committee needed.

of requests live here

L2 Medium

Design system lead

3 day SLA

New variants, prop changes, accessibility uplift, doc rework. Reviewed by the design system lead at weekly triage.

land here

L3 Heavy

Council with RFC

2 week SLA

Net-new components, deprecations, API breaks, brand-mode work. Requires a short RFC and council review.

need an RFC

L4 Heavy+

Executive sponsorship

Cycle planning

Tooling change, vendor swap, multi-brand strategy, budget. Goes to exec sponsorship at cycle review.

are strategic

Light L1, mostly self-serve docs

Medium L2 with weekly triage

Heavy L3 with RFC, L4 if strategic

Who does what

Tiers and SLAs answer the timing question. RACI answers the accountability one. The full matrix lives in the governance report with rows per request type, but the four roles boil down to this.

RACI per request type

One Accountable per task. R and A can be the same person.

R

Responsible Does the work

A

Accountable Owns the outcome

C

Consulted Gives input before

I

Informed Kept in the loop

Worked example, a new component request across all three platforms:

Phase

Contributor

DS Designer

Platform Lead

DS Lead

Council

Submit request

RA

I

-

Triage and classify

C

RA

I

-

Design spec

C

R

C

A

-

Cross-platform review

I

R

A

I

Implementation (per platform)

-

C

RA

I

-

Release and comms

I

R

A

I

Excerpt. The governance report carries the full matrices for token changes, bug fixes, breaking changes, and deprecations.

Maturity roadmap

Three columns, ranked by effort. V1 is the quick wins, what the team can ship in weeks with tools already in their hands. V2 is the next layer, more refined automation that needs real engineering investment but pays back in throughput. Dream State is the longer-horizon work: high effort, mature systems, and integrations beyond today's scope.

Capability

V1 - Foundation

V2 - Automation

Dream State

Intake

One form for all

Smart questions adapt based on request type. Single entry point.

Auto-routing

Power Automate classifies and routes to the right team automatically.

Predictive triage

A machine-learning model auto-classifies request complexity before human review.

Triage

Weekly review

Friday triage meeting, 24-48hr response SLA.

SLA-driven

Automated SLA tracking with escalation paths.

Real-time dashboard

Power BI live metrics with predictive bottleneck alerts.

Tracking

Spreadsheet log

Manual tracking of all requests and outcomes.

ADO integration

Auto-created work items with full audit trail.

Contribution scoring

Gamified contribution metrics driving team engagement.

Excerpt from the full maturity roadmap.
The complete version in the governance report covers the full capability set across the design system lifecycle.

05

Automation

The intake flow

For an enterprise this size, design system intake is either automated and auditable or it's chaos. Three brands, three platforms, dozens of squads. Manual triage was never going to scale, and a paper-trail-by-email approach was never going to hold.

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.

One Microsoft Form triggers 31 Power Automate actions across 6 connectors. Every submission produces five simultaneous outputs:

A Teams Adaptive Card for the design system team
A team email with full request detail
A confirmation email for the requester
An Azure DevOps work item pre-routed and pre-tagged
A SharePoint log entry for audit and reporting

Zero manual steps from submission to ticket. Triage itself stays human, a weekly Friday review by the governance team, with the full automation roadmap mapped as tickets and epics for the team to execute.

Before

No front door

Requests came from everywhere: DMs, channels, hallway chats, Figma comments, calls. There was nowhere to direct them, and each one was captured manually by whoever happened to catch it. Things slipped through the cracks.

No front door. No formal process. No consistency.

Teams DM

Direct message

Teams Channel

Channel post

Figma Comments

Design feedback

Confluence

Page comments

Hallway

In-person chat

Phone Call

Verbal request

Teams Meeting

Verbal request

Email

Outlook chain

Azure DevOps

Ticket comments

After

One front door

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.

Microsoft Forms

Capture request details

Power Automate

Process and route requests

Teams Card

Adaptive Card for instant visibility
Team Email

Request details sent to the relevant team
Confirmation

Receipt with ID sent to the requester
Azure DevOps

Story or Bug created and linked automatically
SharePoint

Request log for tracking and reporting

1

Single entry point

All requests start in the intake form

6

Outputs

Teams, 2 emails, SharePoint, ADO, Power BI

Instant

Confirmation

Automated receipt sent to the requester

100%

Visibility

Track every request from start to finish

Inside the flow

The flow tree below shows the actual Power Automate structure: 31 actions, 14 variables, 6 connectors, and a Switch block handling four urgency tiers.

DS Intake

Notify + Email + ADO

Power Automate

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.

31 actions · 14 variables · 6 connectors

DS Intake - Notify + Email + ADO

Get response details

Get user profile (V2)

Post card in channel

Initialize variables (14)

Switch (Urgency)

Case 1

urgency 1

Case 2

urgency 2

Case 3

urgency 3

Case 4

urgency 4

Send email (V3)

+ 12 more actions

What the team receives

A single Power Automate flow handles conditional routing, variable manipulation, and parallel branches. Every submission fans out across the surfaces the team already lives in. Each tab below shows the actual output.

Microsoft Forms · Intake

One front door for every request

A nine-field Microsoft Form replaces eight scattered intake channels. Two minutes from "I have a thing" to a structured ticket on the right board.

9 fields about 2 min Triggers Power Automate

Captures everything for triage. Title, description, type, platform, urgency, team, links, attachments.
Five outputs fan out instantly. Teams card, two emails, SharePoint row, ADO work item.
No meeting required. The form replaces the back-and-forth scoping conversation.

Microsoft Forms

Design System Request

Submit bugs, request new components, or ask for design system reviews.
* Required

1. Title *

2. Description *

3. Request type *

4. Platform(s) *

Web

Native (iOS & Android)

Web & Native

5. Urgency *

Teams · Adaptive Card

The team sees it where they already work

An Adaptive Card hits the DS Intake channel within seconds. Requester, type, urgency, links surfaced inline so triage starts before someone has to ask.

Instant post 8 fields inline

One-click jump. Open the auto-created ADO work item or jump to all responses in SharePoint.
No app-switching. The team's existing Teams workflow becomes the triage surface.
Urgency at a glance. Coloured pill on every card. Triage prioritises before opening it.

Microsoft Teams

Low

DS Intake Request

Bupa Design System

Button hover state on mobile

The primary button does not show a hover state on mobile Safari. When tapping, there is no visual feedback that the button has been pressed.

Submitted byNate Mills

TypeBug report

PlatformWeb

UrgencyLow

DepartmentDesign Experience team

TeamProduct

LinksLink 1, Link 2

Attachmentsscreenshot.png, specs.pdf

View in Azure DevOpsView All Responses

Outlook · Email

The formal record

A structured email sent to the DS team's distribution list alongside the Teams notification. Two channels means nothing slips through.

Searchable archive Distribution-list ready

Audit trail by default. Mailbox archives are searchable and exportable.
Three-tile summary. Type, Platform, Urgency scannable in the inbox preview pane.
Requester contact inline. Follow-up without lookup.

Outlook

From: noreply@bupa.com.au | Subject: DS Intake: Button hover state on mobile

Design System Intake Request

New request

Button hover state on mobile

The primary button doesn't show a hover state on mobile Safari. When tapping, there's no visual feedback that the button has been pressed. Affecting the checkout flow on iOS devices.

Urgency

Low

Type

Bug report

Platform

Web

Confirmation back to the requester

A matching receipt to the person who filled out the form. Same Bupa chrome, different message: confirms what was captured and surfaces an escalation path if it can't wait for triage.

Auto-sent on submit Closes the loop

Personalised greeting. Pulls the requester's name from Azure AD so the receipt feels human, not robotic.
Echoes what was captured. Title, description, urgency, type, platform, links, attachments, all repeated back so the requester can sanity check.
Escape hatch for blocking work. "Need help sooner?" links straight to the team's channels.

Outlook

From: noreply@bupa.com.au | Subject: DS Intake: Button hover state on mobile

✔ All sorted, Nate.

We've received your request and added it to the queue. We'll review it shortly and be in touch. Thanks for reaching out!

Your submission

Button hover state on mobile

The primary button doesn't show a hover state on mobile Safari. When tapping, there's no visual feedback that the button has been pressed. Affecting the checkout flow on iOS devices.

Urgency

Low

Type

Bug report

Platform

Web

Your Links

Link 1 · Link 2

Your Attachments

screenshot.png · specs.pdf

Need Help Sooner?

Reach out to our team on Microsoft Teams

Design Native Web

Development Native Web

SharePoint · Request log

Every request, one row

A SharePoint list with fourteen columns sourced from three feeds: the form, the requester's Azure AD profile, and runtime metadata.

14 columns 3 sources

Single source of truth. Filterable, sortable, exportable.
Power BI feeds from this. Volume, SLA, aging all from these rows.
Lifecycle captured. Triage status updated as the request moves.

Bupa Design System / Site contents

Bupa/Design System/DS Intake/Requests

Requests

14 columns · 3 data sources · live since 2025

Search this list

New Share Quick edit Filter Group by: Status

31 items

Title	Requester	Type	Urgency	Submitted
Triage 2 items
Button hover state on mobile Web · Connected Care	NMNate Mills	Bug	Low	2 min ago
Add empty state for claims list Native iOS · Member	ACA. Chen	Story	Medium	1 hr ago
In progress 1 item
Tooltip arrow renders behind modal Web · Foundation	PKP. Kowalski	Bug	High	3 hr ago
Done 2 items
Token warm-grey/600 contrast issue Web · Tokens	LSL. Smith	Bug	Medium	Yesterday
Card padding inconsistent on Android Android · Components	MWM. Watson	Bug	Medium	2 days ago

Azure DevOps · Work item

Pre-routed, pre-tagged, ready to triage

Power Automate creates the ADO work item immediately on submit. Triage owner opens it on the right board with platform, urgency, and team tags applied.

Auto-routed 5 auto-tags

Bug or Story routing. Work item type set from the Request Type field.
Right board on day one. Web on Web board. Native on iOS and Android boards.
Linked to SharePoint row. Round-trip from work item to source request.

dev.azure.com / Bupa / DesignSystem

Boards/Web DS/Sprint 47/Work item 84217

Bug | Bug 84217 Triage

Link Save

Button hover state on mobile

Details Discussion History Related work Attachments (2)

Description

The primary button does not show a hover state on mobile Safari. When tapping, there is no visual feedback that the button has been pressed. Affecting checkout flow on iOS devices.

Steps to reproduce

1. Open the checkout page on iOS Safari. 2. Tap the primary CTA. 3. Observe no hover or active visual feedback.

Hub and spoke: one canonical path to the dashboard

The architecture is hub and spoke: each automation flow attaches its own SharePoint list to capture historical data, and all spokes feed a single Power BI dashboard. The intake pipeline shipped as the first spoke. The remaining spokes and the dashboard itself are mapped as tickets and epics for the team to execute against the same pattern.

Why hub-and-spoke

Without a canonical store, every tool becomes its own silo with its own truth. The hub ends that.

Capability, not report

Power BI is replaceable. The SharePoint schema, flow graph, and spoke contracts are the asset.

Extends cleanly

New spokes (GitHub, Loop, token CI) plug into the hub without rewriting downstream reporting.

Design System Analytics Dashboard

Power BI Roadmapped, not yet built

A single Power BI dashboard fed by the Figma Library Analytics API, webhook logs, and the SharePoint hub. Each metric turns the day-to-day governance work into numbers leadership can act on, so those conversations run on evidence instead of opinion. The team owns the build, with tickets and epics mapped per metric, so the dashboard lights up bit by bit as each spoke comes online.

Component popularity: most and least used components across the org

Adoption rates: which teams use which libraries and how frequently

Library health: component counts, last publish dates, approved status

Token coverage: semantic tokens vs raw values across libraries

Design System Health

Components

247

+12 this month

Adoption Rate

84%

+3% vs last quarter

Library usage by team

Web

iOS

Android

Email

CMS

Active Libraries

6

1 stale (>6mo)

Token Coverage

91%

semantic vs raw

Most used components

Button

Input

Card

Modal

Roadmapped, not yet built

Illustrative layout, sample data shown

06

Outcomes

Six months, measured

Six months of consolidation, governance, and automation. Here is what changed, in numbers you can check.

Token consolidation

1,714to450

Tokens consolidated across platforms into one canonical source of truth.

Single source of truth established

74%reduction

Library consolidation

131to3

Libraries audited, then consolidated into a roadmap target of three workspaces.

Alpha rationalisation

415to22

Alpha tokens rationalised into a single overlay model.

Intake channels

8to1

Scattered intake channels consolidated into one Microsoft Forms pipeline.

Brand coverage

3 × 3

Brands and platforms unified on a single token library.

Delivery formats

3 formats

Excel, Figma Variables, and W3C DTCG JSON.

Time reclaimed

~18h

Designer and engineer hours per week reclaimed through the live intake pipeline.

The new architecture, governance framework, and intake pipeline all shipped inside the six months and went straight to the team. For the legacy component re-tokenisation I recommended a phased rollout, with tickets and epics mapped per workstream so the team has a clear backlog to work through. The semantic tokens are platform-agnostic, with platform-specific transforms at the output layer, so adding a brand is a configuration change, not a rebuild.

What the audit identified

Six structural workstreams surfaced by the audit, each mapped to a target in the consolidation roadmap.

Foundation

One library, clear names, consistent rules.

01

Single library

80% fewer5→1

Five source files were maintained independently, with duplicate tokens and conflicting values across platforms.

Consolidated into one source of truth covering all three brands.

Naming conflicts

Aligned

The same token name held different values across platforms. grey.500 was #929ba2 on native and #21272a on web.

Web values adopted as the baseline, platform exceptions documented for accessibility.

Naming convention

W3C DTCG

Mixed spelling and case (cool-grey, coolgrey, coolGrey) that build tools read as three different tokens.

Standardised to kebab-case per the W3C DTCG spec, with a migration map for legacy names.

Colours

Unified colour scales and aligned brand palettes.

02

Colour families

52% fewer27→13

Native and web carried 27 overlapping colour families, many of them near-duplicates.

Consolidated to 13 canonical families. 14 deprecated, including Cyan, Indigo, Tangerine and Evergreen.

Colour scales

31% fewer16→11

Web and native used 15 and 16 scale stops, several of them non-standard.

Standardised to 11 stops (50 to 950), symmetric for dark mode inversion.

Neutrals

One grey scale instead of three.

03

Grey palettes

60% fewer5→2

Three disconnected grey ramps drifted in value between platforms.

Unified to two intentional scales, cool grey and warm grey.

Ink token

Merged

A separate Ink token (#111c24) sat almost on top of grey-950 (#121517), adding maintenance cost.

Deprecated and migrated to grey-950.

Alpha

One transparency scale for all platforms.

04

Alpha scales

95% fewer415→22

Native carried 21 transparency stops and web only 7, with a naming collision where the legacy alpha-100 meant solid and the new alpha-100 meant 10 percent.

Consolidated to 22 tokens, 11 standardised stops each for black and white.

Migration

Typography and spacing now in Figma Variables.

05

Token migration

149tokens

149 typography, dimension and component tokens lived only in code and docs, invisible to designers.

All 149 migrated to Figma Variables, with brand differences handled as modes.

Semantics

Same names for the same things, everywhere.

06

Naming conventions

Unified

Semantic names were fragmented: native used iOS-derived labels, both platforms used tool-derived stroke names.

Adopted a foreground, background, border vocabulary aligned with Carbon, Polaris and Primer.

Accent colours

Added

Brand-specific intent tokens limited design flexibility when onboarding a new brand.

Generic, expandable accent colour slots added, ready for any brand.

What I delivered

Beyond the token architecture and governance framework, I left the team a full set of artefacts built to keep working after I did.

Primary deliverable

Figma Variables

450 tokens · 5 libraries → 1. Single source of truth for Bupa, Blua, and Mindplace.

SSoT spreadsheet

Microsoft Excel

Editable master with all 450 tokens, mappings, and migration notes.

Design tokens JSON

W3C DTCG Format

Style Dictionary-ready JSON. Direct pipeline to code.

Audit reports

Interactive HTML

Three reports: 1,714 tokens with cross-platform comparison, 131 libraries audited, and governance maturity scored against industry standards.

Colour explorer

Interactive HTML Tool

Browsable colour families, scales, and alpha variants with live swatches and token metadata.

Contrast checker

Interactive HTML Tool

WCAG AA/AAA pass-fail testing across every foreground-background pair in the token set.

Audit tickets

Azure DevOps

Every token inconsistency captured as a tracked work item with platform tag, severity, and owner.

Governance Framework

Documentation

Contribution model, triage framework, and maturity roadmap.

Power Automate Pipeline

1 Flow · 31 actions

Conditional routing, variable manipulation, and parallel branches powering the intake infrastructure.

Worked closely with Nate on a design system audit, and he delivered exactly what you want from someone in that space, with clarity, rigour, and practical impact.

He quickly got across a complex environment and cut through the noise to identify where the system was genuinely adding value vs where it was creating friction. What stood out was his ability to translate that into clear, actionable recommendations, not just critique, but a path forward that teams can actually implement.

Nate balances strong systems thinking with a pragmatic, delivery-focused mindset. He's also easy to work with, brings stakeholders along, and keeps the focus on outcomes rather than theory.

If you need someone to assess, stabilise, or evolve a design system with real-world constraints in mind, Nate is a solid choice.

Benson Low

Product, Design & Research Leader, Bupa Australia

07

Reflections

Looking back

What I would carry forward

I set up the governance infrastructure 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 settled before V1 ships. The 7-3-3 split (7 locked, 3 deferred, 3 evolving) let stakeholders trust that the foundation was solid, while being honest that some decisions need real use before anyone can call them final.

The token consolidation was also a reminder to build accessibility in at the foundation, not bolt it on later. I checked WCAG 2.1 AA contrast across every semantic surface and text token pairing.

What I would explore next time

Wiring up the Figma Enterprise API webhooks would be a strong next step. Watching for new libraries the moment they are created would stop sprawl creeping back in while the consolidation is still underway.

I would also spend more time early on agreeing a shared vocabulary with the native development team. Sorting out semantic naming together, sooner, saves a lot of back-and-forth at handoff.

Tools and skills applied

Figma Design Tokens (W3C DTCG) DesignOps Power Automate Azure DevOps Power BI SharePoint Microsoft Forms WCAG / Accessibility Style Dictionary Notion Confluence Multi-brand Theming Cross-platform Tokens Claude Code AI agents & skills AI-assisted prototyping

Features I would build next

Triage assistant 12s

Routing this to the iOS team. Looks like a component-level enhancement, not a system change.

94% confident Auto-route

Automation

Predictive triage

A machine-learning model that learns from past intake tickets and automatically routes each new request to the right team, so designers and engineers only review the ones that really need a human eye.

tokens.json

"background.brand-primary": { // brand modes "bupa": "#0079C8", "blua": "#00B6BD", "mindplace": "#7C3AED"}

Tokens

Multi-brand token pipeline

Three brands, three platforms, one pipeline. Bupa, Blua, and Mindplace feed the same Style Dictionary build, with native code outputs for iOS, Android, and web. Each brand becomes a mode in the same library, no fork needed.

System health Mon 09:00

312

Components

87

Styles

98%

Coverage

Analytics

Figma API health checks

Weekly automated scans of every Figma library that surface unused components, orphaned styles, and naming drift, so the system stays clean without anyone having to audit it by hand.

#247 merged

Add Card.elevated variant

nathan wants to merge into main

✓Token coverage2s

✓A11y checks11s

✓Visual regression42s

✓Storybook entry1s

Governance

Contribution playbook

Step-by-step guides, templates, and review checklists that make it easy for any designer to contribute new components, with automated checks catching issues the moment a pull request lands.

Root cause analysis

Design systems grow faster than the rules that govern them. Teams ship. Libraries multiply. Before you know it, there are more than anyone expected. This is normal. It happens to every maturing system.

Growth outpaced governance

The team focused on shipping and supporting the business. Process and documentation lagged behind, normal for a young team doing their job well.

Phased rollout with maturity model

Tribal knowledge

How things work lived in people's heads, not documentation. The answer you got depended on who you asked.

This document and decision records

No front door

Eight scattered intake channels with no formal process. Requests captured manually, nothing tracked, nothing triaged.

Microsoft Forms intake with Power Automate routing

No decision framework

“Who decides?” had a different answer depending on which team you asked. Conflicts resolved by whoever was loudest.

L1 to L4 decision authority with RACI

Tokens grew without abstraction

1,714 tokens, 415 alpha variants, 27 colour families. Each brand and platform built its own layer instead of sharing primitives.

Three-tier model with brand modes

Manual triage absorbing time

Friday meetings burning hours of senior time. Requests routed by memory, not process, with no SLA tracking.

Automated routing with SLA visibility

Name	Nate Mills
Job Title	Design System Consultant
Department	Digital
Email	n8mills@bupa.com.au
Team	Connected Care

Design Once Ship Everywhere.

Audit and untangle

Industry standard audit

Target token architecture

Reference automation, shipped

Owned backlog for the team

What I found

Audit at a glance

How they got here

Design system findings

Duplicate primary buttons

Deprecated libraries still in active use

Cross-platform mismatch

Working files mixed with published libraries

Naming collisions across platforms

Legacy styles drifted unmaintained

Nothing safe to delete

Decisions lived in Teams chats

No contribution model

Token migration blockers

Alpha scale naming collision

Incompatible alpha scales

Naming inconsistencies causing silent failures

Token collection name typos

Coloured alpha tokens

One token system

Built to the W3C Design Tokens spec

Three-tier model

Three tiers, each built on the last

Inside the primitive layer

The alpha token decision

How it's built

V1 readiness

From request to owner

Need raised

Request submitted

Work sized

Path assigned

Next step set

Triage framework

Typical requests

Typical requests

Typical requests

Then who decides

Who does what

Maturity roadmap

The intake flow

No front door

One front door

Inside the flow

What the team receives

One front door for every request

The team sees it where they already work

The formal record

Confirmation back to the requester

Every request, one row

Pre-routed, pre-tagged, ready to triage

Hub and spoke: one canonical path to the dashboard

Design System Analytics Dashboard

Six months, measured

Token consolidation

Library consolidation

Alpha rationalisation

Intake channels

Brand coverage

Delivery formats

Time reclaimed

What the audit identified

What I delivered

Primary deliverable

SSoT spreadsheet

Design tokens JSON

Audit reports

Colour explorer

Contrast checker

Audit tickets

Governance Framework

Power Automate Pipeline

Looking back

What I would carry forward