Skip to main content
01 · Define the standard
2023 – 2025

Foundations: from design system to shared standard

Before you can scale design judgment, teams need a shared foundation to reason from. This is the story of building one across AFT: from design-system and token architecture, to a framework-agnostic UX standard across a 500+ product ecosystem, to the tooling that made the standard self-serve. It's also where the through-line of my later work first appears: turn a standard into a system, and turn the system into tooling that scales.

Scope
Design-system foundations + cross-org standards across AFT
Focus
Token architecture, accessibility, adoption without mandate

Foundations: the design system (2023–24)

I joined AFT's design-system team as the lead UX designer for component creation, Figma libraries, and adoption. Its visual language traced back to a 2019 stylesheet-era foundation, before coded components, which left gaps in themeability, accessibility consistency, and scalability as the ecosystem grew past 50 product teams. Before expanding the component roadmap, the lead front-end engineer and I rebuilt the primitives everything depends on.

Token architecture

The largest lift was rebuilding the token taxonomy so the system behaved like infrastructure: a small set of primitives (color ramps, sizing ramps, multipliers), with themes defining defaults and the system deriving the tokens each component and surface needs. A layered model (foundation → platform → local) made trade-offs explicit and let the system scale beyond color without resetting the baseline.

Durable vs. adaptable

To avoid both a one-size-fits-all system and a local free-for-all, I split semantic tokens into durable (shared surfaces, default text, baseline states, preserving familiarity across themes) and adaptable (brand expression, navigation emphasis, primary actions, controlled variance for audience needs). Surfaces were intentionally durable: keeping surface relationships consistent preserves elevation and hierarchy, especially in dark mode where shadows are unreliable. Operator experiences kept blue for continuity; Associate themes introduced purple to differentiate while keeping the UI calm.

Contrast as a system constraint

Accessibility was designed into the palettes, not bolted on as a last-mile check. Ramps were generated with contrast-based tooling (Leonardo) to establish accessible relationships across light and dark, then tuned against real component pairings, so the system does most of the accessibility work up front and teams only validate custom compositions. We shipped refreshed Operator and Associate themes across Figma and code, with beta pilots validating the direction across customer teams.

The standard: Common Experience (2024–25)

That foundation set up the next problem. AFT runs 500+ products built by autonomous teams on different stacks, often without shared UX foundations, creating fragmentation that duplicated effort, extended onboarding (4–8 weeks per process path), and pushed inconsistency onto Operators moving across 40+ tools. I was a lead UX designer on Common Experience, focused on the cross-product requirements and, harder than the requirements themselves, the mechanisms teams needed to adopt them.

I authored the Common Experience Requirements (CER): a shared, framework-agnostic baseline any product could meet regardless of its front-end stack, split into style-and-presentation and interaction-and-usage behavior with a strong accessibility lens. The rollout was built for autonomous teams (phased adoption, experience audits, lightweight intake and office hours) so teams adopted within their own roadmaps rather than being mandated into a migration. Incentive over mandate: the compliant path was made the easy path.

The target impact framed the stakes: $250MM+ in annualized savings, a 3.75% improvement in Veteran Curve efficiency, and a 25–35% reduction in UI development effort through reuse and clearer standards, against a documented baseline of ~140 requirements.

The bridge: turning the standard into tooling

A standard that lives in a document gets referenced; a standard built into tooling gets used. With limited program capacity, I designed and built a Figma plugin that validated designs against the requirements inside designers' existing workflow, flagging issues like contrast, typography, and detached components before they became review bottlenecks.

It was my turning point into UX engineering, and the first instance of the instinct that defines everything after: don't just publish a standard, build the system that applies it for people. That instinct is exactly what the flagship scales.

Where it led

As program capacity shrank, “scale judgment through systems, not headcount” became the through-line for everything after. It grew into a full AI design-tooling platform for AFT, the flagship of this portfolio, and the back half of the arc.

Outcomes

  • Rebuilt design-system foundations with modern token architecture and a durable-vs-adaptable model, enabling scalable theming across Operator and Associate contexts in Figma and code
  • Authored the Common Experience Requirements (~140 requirements) as a framework-agnostic baseline teams could align to
  • Established the rollout mechanisms (intake, office hours, phased adoption) that let a decentralized org align without mandate authority
  • Shipped a Figma validation plugin that turned the standard into a self-serve check, the model the later platform work scales