Design Systems · 2019–Present

Building Aero
from zero

How I built SpotOn's design system from nothing and led it through a rebrand, three major versions, and a governance model the org actually uses.

Role
Design System Lead
Company
SpotOn
Timeline
2019–Present
Status
Active
58 Components 24 Platforms 30+ Micro frontends

Nobody was building from the same map

SpotOn was acquiring products faster than anyone could keep them consistent, and no one owned the fix.

Every team made its own calls on color, spacing, and components. No shared reference, no incentive to align.

There was no mandate to build a design system. We built one anyway. By the time leadership saw what we had, it was already infrastructure.

NEW — create from screenshots of pre-system products img/cs1-fragmentation.png

The same component rendered four different ways across SpotOn products before the system existed

So we treated the system like a product and talked to the users first

Before building anything, we researched how designers and engineers actually worked.

We interviewed the full design team and a set of developers, structured around their real workflow: how they used the kit, what worked, what didn't.

What came back was uncomfortable. Too limited, tied to some products only. Zero design-code parity. No guidelines, no visibility, uneven adoption. Most teams build the library first. We built the research first.

NEW — pull from research FigJam or redraw img/cs1-research-artifact.png

Interview synthesis — the system was treated as a product before a single component was built

If it didn't exist in both design and code, it didn't exist

We made design-code parity a hard release requirement, and it exposed every gap.

Every component moved through four phases (planning, ideation, production and testing, documentation and release) with visual and accessibility QA as gates. If a component couldn't exist identically in design and code, it wasn't done.

The rule surfaced two problems. Designers in Figma had no model of how things get built, so simple-looking components turned out hard. And Figma and Storybook used different names, so the two teams read different maps. We fixed both in grooming: design and engineering in one room, agreeing on names before anything got built.

NEED TO EXPORT — Figma img/cs1-nexus-early-library.png

Nexus, 2020 — the first mirrored library across Figma and React

NEW — create from Figma + Storybook screenshots img/cs1-naming-mismatch.png

Different names for the same thing in Figma vs Storybook — then the agreed shared name

NEW — screen-record from Storybook img/cs1-date-picker-states.gif

The date picker — looks simple in a static frame, complex to build across all its states

The turning point wasn't the team, it was getting the org in the room

A single all-hands demo shifted the design system from our problem to shared infrastructure.

The team grew from one solo designer in 2020 to a cross-functional unit by 2022. But the turning point was a presentation.

In 2023, the design system lead engineer and I presented to the full product org for the first time. We showed the cost of fragmentation, then a live demo of light and dark mode switching via tokens. Product leads asked how to prioritize adoption. Engineering asked how to contribute. The framing changed from "the DS team's problem" to "our infrastructure."

✅ HAVE IT — all-hands deck img/cs1-architecture-layers.png

The full stack — one token definition, four platform outputs

NEW — screen-record the toggle in Figma or a live product img/cs1-light-dark-demo.gif

The 2023 all-hands demo — light to dark in real time via tokens, the moment that turned the room

Tokens let one definition reach every platform

Design tokens turned an expensive, manual color change into a single edit compiled to every platform.

Engineering built Token Alchemy, the pipeline that translates design attributes into any framework's format. My team and I defined the taxonomy: a five-part naming convention (Type, Element, Role, Variant, State) where the name is the documentation. color.container.brand.strong.none tells you what it is and where it goes before you look it up.

That enabled the refresh. Nexus became Aero v2.0, an evolution, not a restart, so no product team began again. The typography update (Roboto with Poppins) cut screen real estate 14% and made financial data easier to scan. The full v2.0 proposal (OKLCH ramps, desaturated dark mode, AI-optimized token structure) is designed and awaiting prioritization.

✅ HAVE IT — Aero 2.0 deck img/cs1-roboto-poppins.png
✅ HAVE IT — Aero 2.0 deck img/cs1-dark-mode-desaturation.png

Roboto vs Poppins (14% screen real estate reduction) · Desaturated dark mode — accessibility driven, not cosmetic

✅ HAVE IT — Token Journey diagram img/cs1-token-journey.png

One token definition, four platform outputs — engineering consumes, not re-implements

NEW — screen-record or build as a short motion piece img/cs1-token-propagation.gif

One token edit updating Figma, web, Android, and iOS simultaneously

NEED TO PULL — Figma / Internal Decks img/cs1-system-evolution.png

Adobe XD → Nexus → Aero v2.0 — same system, three eras

The proof came from the team, not a dashboard

The clearest signal the system worked came from the people using it.

The first real measure was the team's own 2020 retrospective: consistency across products, faster delivery, faster style updates, better design-engineering communication, the first web and Android libraries.

By Aero v2.0 that signal had scaled to 58 components across 24 platforms, and a taxonomy that absorbed a full rebrand without one team restarting. A color change that once meant coordinating dozens of products became a single edit.

"Does it make the boat go faster? Aero did."

— Manager, 2025 performance review
✅ HAVE IT — Nexus deck img/cs1-maturity-progression.png

No System → Style Guide → Pattern Library → Design System → Agentic Design System

NEW — pull from team quotes slide img/cs1-team-quotes.png

The retrospective in their own words — proof from the team, not a dashboard

What I'd do differently: bring engineering in at the problem, not the build

The system got better the moment engineering became a co-owner instead of a recipient. I'd bring them into problem definition, not the build.

Next case study

The operating system

The lifecycle, rituals, and federated model that made Aero stick across 30+ product teams.