One system.
Five brands.
89% less effort to ship.
Atom is the multi-brand design system I built at DragonPass — a token-driven foundation that themes an entire product for any partner brand, and ships in days instead of months. Wired end-to-end with AI.
Context
Every partner channel was rebuilt from scratch.
DragonPass ships products through many partner brands — eSIM, transport and other non-lounge services. Each new channel was developed chimney-style: the full product re-built at ~100% effort, separately, across iOS, Android and web.
The result was high coupling, low reuse and siloed work. Three platform teams produced three versions of the same thing, and every brand started from zero.
With a $50m non-lounge revenue target riding on how fast new partners could go live, duplication wasn't a tidiness problem — it was the bottleneck on revenue.
The brief I set myself: separate what changes between brands from what stays the same, so a channel becomes a configuration, not a rebuild.
Architecture
Atom separates what changes from what stays the same.
Three Figma files, three token tiers, one attribute to switch brand. Each file owns one layer and references only the layer beneath it — so adding a brand means mapping tokens, not writing code.
Primitive Library
Raw values — the full palette, type and spacing scales. Brand-agnostic; the base every brand draws from.
→Brand Switcher
Intent, mapped per brand. atom.foreground, atom.background, atom.border resolve primitives into meaning — five times over.
Core Component Library
The Atom design system — Button, Input, the Atom badge. Consume semantics only, never primitives.
Brand switches on a single [data-brand] attribute. Dark mode is an orthogonal axis — [data-brand][data-theme] — so themes multiply without multiplying components.
Signature — try it
Switch the brand. Watch the system re-theme itself.
This panel uses the same data-brand token-swap the real system uses. The components below are unchanged between brands — only the resolved tokens move.
Steps, Switch and Tabs are real components from the Atom library. Colours and typeface are the live per-brand values resolved from the Brand Switcher across all five brands.
Foundation
A primitives library that components can't break.
Primitives are the atomic layer — the smallest components every screen is built from. The rule that makes the whole system hold: a primitive never hard-codes a value. It reads a semantic token, which resolves from the active brand's primitives.
That single constraint is why six brands can stay visually distinct and still behave identically. Change a brand and nothing in the component layer moves — the tokens underneath do.
Behaviour, not pixels
Interaction and accessibility live in the primitive; brand lives in the token. The two never tangle.
Accessible by default
WCAG AA contrast is validated automatically, so no brand combination can ship an unreadable state.
Proven across the matrix
Every brand × every component is checked, so a change in one place can't silently break another.
AI
I wired the system to an AI layer — and it changed how we work.
A live bridge between Figma and Claude turns the design system into something queryable, auditable and self-documenting from the source of truth.
Token and variable audits across all six brand collections, component gap analysis, and design-to-code straight from the live files — no manual exports, no stale snapshots. The source of truth stays in Figma.
I had Claude Code generate the component documentation one component at a time from the live files, on a single consistent structure — anatomy, spec, usage, token references per brand, and accessibility — so the docs stay grounded in reality.
Used AI to stress-test the primitive → semantic → component tiers, separate true semantics from component tokens, and find the "no-brainer" tokens worth promoting first.
A REST-based plugin pushes generated documentation frames back onto the Figma canvas — so audits, docs and handoff all start and end in the same place designers already work.
Proof in production
GA started three months late — and launched first.
Two channels, same destination. Investec was a traditional bespoke build. GA ran on Atom's reuse model. The gap is the case for standardisation.
traditional
reuse model
Team impact
Adoption was the real design problem. I solved it with people, not mandates.
A system only works if the team trusts and uses it. I ran one-to-one sessions with every designer to show Atom in practice, then led a group share-and-learn tying it back to the business goal.
I worked shoulder-to-shoulder with engineering — responding to real constraints and adjusting Atom where it needed to flex, rather than defending it rigidly.
And I led with evidence. Documenting impact clearly turned Atom from a design initiative into a proven business tool — leadership came to see it as a smarter way to deliver across the organisation.
That shift in perception, more than any single component, is the result I'm proudest of this year.
Jumped into a live call with the GA team to solve the icon issue and avoid rework for everyone.
— Jay GeorgeKudos for the work on Atom. High five all round.
— Catherine ThomasThanks for jumping on a million design-system requests and bringing new components to life.
— Daniel KenyonThe data clearly shows improved efficiency and cost reduction — a new way of delivering great work.
— Recognised across DP leadershipOutcomes
What the system delivered.
What's next
Make adding a brand a form, not a project.
Maturing the semantic-token layer, baselining impact metrics earlier, and turning brand onboarding into something a non-technical contributor can do by filling in values — so the system scales well beyond six brands without an engineer in the loop.