Token architecture
Three tiers in JSON as the single source, building to CSS custom properties, Swift and Kotlin. One pipeline, one source of truth, no hand-maintained copies.
- primitive/blue-600
- action/primary
- button/bg-rest
- button/bg-hover
Design SystemsMeridian Insurance
One design system across six insurance products
Six products, four front-end stacks, and eleven different buttons that all did the same thing.
- Design system
- Tokens
- Governance
- Client
- Meridian Insurance
- Discipline
- Design Systems
- Engagement
- Design system
- Platforms
- Web, iOS and Android
- Duration
- 16 weeks
- Delivered
- 2024
01The problem
What we walked into
Meridian sells six insurance products, each built by a separate squad, three of them inherited through acquisition. There was no shared library, so every squad had built its own everything.
The audit counted eleven button components, nineteen greys, six date pickers and four separate implementations of the same address form. A brand refresh had been scoped at eighteen months, almost entirely because nobody could say with confidence where the old colours were used.
The previous attempt at a system had failed for a familiar reason: it was built as a Figma library, announced in a town hall, and never adopted, because nothing in anyone's roadmap made room for migrating to it.
02Goals
What the work had to achieve
Agreed in the first fortnight, written down, and used to settle every argument afterwards.
- G01
Name things for intent, not appearance
A token called brand-blue-600 breaks at the next rebrand. A token called action-primary survives it.
- G02
One library, three platforms
The same token source has to produce web, iOS and Android outputs so the platforms cannot drift apart between releases.
- G03
Make adoption part of the work
The system is not delivered when the library ships. It is delivered when products are running on it.
- G04
Design a way to say yes to new components
Without a contribution process, squads will keep building in private, which is how eleven buttons happened the first time.
03UI approach
The decisions that shaped the interface
Four moves that did most of the work. Everything else on the project followed from them.
- 01
The count, first
We inventoried every component and colour across the six products before designing anything. Eleven buttons and nineteen greys on one slide ended a debate that had been running for two years.
- 02
A three-tier token architecture
Primitive values, semantic aliases, component tokens. Squads only ever reference semantic and component tiers, which means a rebrand touches the primitive layer and nothing else.
- 03
Components shipped in migration batches
We released in four batches ordered by how much duplication each removed. Buttons, inputs and the address form came first, so the first migration paid for itself immediately.
- 04
Governance with actual names on it
A contribution guide, a fortnightly review with a rotating seat from each squad, and a documented path for proposing, trialling and promoting a component.
04Components and design system
What got built underneath
The reusable parts, and the tokens they were built from. This is the layer that keeps the interface consistent after we leave.
Form field set
Fourteen input types sharing one label, help, error and required specification. The four address form implementations collapsed into one composed from these.
- field/label
- field/help
- field/error
- field/required
Component documentation
Every component ships with anatomy, states, content rules, accessibility spec and do-and-do-not examples. Undocumented components are not released.
- doc/anatomy
- doc/states
- doc/a11y
05Outcomes
What changed after release
Measured by the client, on their own reporting, over the period noted against each figure.
- Button components
- 11 → 1Button componentsOne component with documented variants replacing eleven.
- Greys in the palette
- 19 → 6Greys in the paletteEach of the six now has a defined semantic purpose.
- Rebrand estimate
- 18mo → 6wkRebrand estimateA palette change is now a primitive token change.
- Products on the system
- 6 / 6Products on the systemAll six migrated within nine months of the first batch.
The slide with eleven buttons on it is still pinned in their design channel. It did more for adoption than the library did.
The audit slide did more for adoption than the library did. You cannot argue with eleven buttons.
06Gallery
Screens and system, laid out
Layout diagrams of the interface as delivered, with a note on what each one is doing.
- 01 / 04
The audit
Eleven buttons and nineteen greys, counted across six products and put on one page.
Interface layout diagram from the Meridian Insurance project.
- 02 / 04
Token tiers
Primitive, semantic and component tiers, with squads referencing only the upper two.
Interface layout diagram from the Meridian Insurance project.
- 03 / 04
Form field set
Fourteen input types sharing one label, help, error and required specification.
Interface layout diagram from the Meridian Insurance project.
- 04 / 04
Component docs
Anatomy, states, content rules and accessibility spec, required before any component ships.
Interface layout diagram from the Meridian Insurance project.
07Take it with you
The one-page version
Everything above, condensed to plain text. Copy it into a brief, or download it to circulate internally.
Case study summary
Plain text, ready to paste into a brief or a board pack. Saves as baseline-studio-meridian-design-system-summary.txt.
BASELINE STUDIO / CASE STUDY SUMMARY
================================================================
Client: Meridian Insurance
Project: One design system across six insurance products
Discipline: Design Systems
Engagement: Design system
Platforms: Web, iOS and Android
Duration: 16 weeks
Year: 2024
OVERVIEW
================================================================
Meridian Insurance ran six products across four front-end stacks with no shared library. An audit counted eleven button components, nineteen greys, six date pickers and four separate address form implementations. A brand refresh had been scoped at eighteen months.
We built a three-tier token architecture in JSON producing web, iOS and Android outputs, released components in four migration batches ordered by duplication removed, documented every component with anatomy, states, content rules and accessibility spec, and set up a fortnightly contribution review with a rotating seat per squad.
Delivered across 16 weeks: a full cross-product audit, a token pipeline with three platform outputs, 38 documented components including a fourteen-type form field set, a contribution guide, two adoption workshops and a migration plan with named owners.
Results: eleven buttons reduced to one, nineteen greys to six semantic values, the rebrand estimate cut from eighteen months to six weeks, and all six products migrated within nine months.
OUTCOMES
================================================================
11 → 1 Button components
One component with documented variants replacing eleven.
19 → 6 Greys in the palette
Each of the six now has a defined semantic purpose.
18mo → 6wk Rebrand estimate
A palette change is now a primitive token change.
6 / 6 Products on the system
All six migrated within nine months of the first batch.
CONTACT
================================================================
Baseline Studio
studio@baseline.design
+1 (415) 555 0142
Figures describe a specific product, team and period, and are
published to explain the work rather than to predict a result.05Start a project
Working on something similar?
Tell us where your product is getting stuck. We will tell you honestly whether this is the kind of problem we are good at, and what we think it would take.
- Prefer email
- studio@baseline.design
- Current availability
- Taking on two engagements for the coming quarter.
- Typical reply time
- Two working days, from a partner rather than a form.