DESIGN SYSTEMS · 2024-2026

The system is the set of agreements, not the component library.

Rebuilding Design System Thinking in a Scaling SaaS Product

3 min read

FigmaDesign TokensAtomic DesignGovernanceB2B Travel

This work is under strict NDA. Client specifics are withheld; the role, the process, and the decisions follow. Artifacts shown are recreated, data is illustrative, and the client appears as an industry descriptor only.

01 · The audit

Make the drift undeniable before proposing anything

One undocumented decision had created three downstream inconsistencies.

Seventeen near-identical buttons, built by different people at different times. Across a B2B travel platform spanning flights, hotels, rail and car rentals, the shared parts had forked until no one could tell what was clickable.

Nobody set out to fragment the system. It accumulated one sprint at a time.

The audit reframed it from "our UI looks inconsistent" to "this structure creates measurable overhead, here is the evidence." Then it moved upstream: semantic tokens under everything so decisions propagate, and component status, not enforcement.

Recreated concept, illustrative. A B2B travel platform, abstracted.

02 · The cascade

Put tokens under everything so decisions propagate

Instead of a button storing a hard-coded hex value, it references a semantic token that is defined once and propagates everywhere.

Foundations, components, documentation, and a system hub, each tier with a clear purpose, so a change made at the bottom of the cascade lands consistently at the top. The interactive recreation below shows the cascade and the design-code parity it makes checkable.

Change the foundation and watch it move. Break the link and watch it drift.

Recreated concept, illustrative. A B2B travel platform's design system, abstracted.

03 · The governance

Govern with status, not enforcement

The hardest problem is not building the system, it is preventing it from fragmenting again.

A low-friction proposal path and clear component status let active features pull the system into use. When an engineer reached for a pattern and found it already solved, the system earned its credibility.

Component status

ButtonStableUse freely
InputStableUse freely
SelectIn reviewUsable, may still change
Date fieldExperimentalOpt in, expect change
Legacy modalDeprecatedMigrate to Modal

The proposal path

ProposeIn reviewStable

Status signals maturity, it does not block. Anyone can propose; adoption is what promotes a pattern. Nothing is enforced, so nothing gets worked around.

Recreated concept, illustrative. A B2B travel platform's design system, abstracted.

04 · The foundation

A shared language for how the product should look, behave, and grow.

Inconsistency is rarely the root problem, it is a symptom of missing structure and undocumented decisions.

The audit and the business case won investment for a dedicated design-systems team. The system became the foundation the larger team built on: the surface evolved, the components and the agreements held.

Duplicated components consolidated into flexible building blocks; the UI shifted from whatever the last sprint produced to a coherent product language.

Doing this as a solo designer reinforced something about advocacy: the audit framework was not just a research method, it was a communication tool. Framing the problem in terms of business alignment and delivery cost made a different kind of conversation possible about the value of the work.

The outcome

The audit won investment for a dedicated design-systems team.

The system became the foundation the larger team built on.

What changed

OwnerOne solo designerA dedicated systems team
The systemOne undocumented fileThe foundation they build on
The UIWhatever the last sprint shippedOne coherent product language
The frame“Our UI looks inconsistent”“This creates measurable overhead”

Recreated concept, illustrative. A B2B travel platform, abstracted; no client figures shown.

Thanks for reading

Next case

CHIPAI + Design Systems · 2026