The system underneath

Ten years building design systems for enterprise, fintech, media, and consumer products — the token architecture, governance, and design-to-code pipelines that hold a product together when the teams building it never meet.

Role

Design Systems Architect
UX Design Lead

Focus

Token architecture
Governance
Design-to-code
AI-readiness

COntext

Warner Bros. Discovery
AWS
GoDaddy
Dell

Years

2017 - present

One component · Three meanings · One definition underneath

Hard-stop conflict
Blade Runner 2049 can't air after 2026 in this window.
wt-toast-color/border/danger #E5383B
Window closing soon
3 titles in this proposal expire within 30 days.
wt-toast-color/border/warning #E0760C
New titles synced
142 titles added from the latest WBD catalog drop.
wt-toast-color/border/information #4E88FF
Hover to expand

One toast definition — the left accent, icon, and title all resolve from the semantic token. Three meanings design, engineering, and a model read the same way.

TOP

A design system isn’t a component library. It’s the set of decisions a product can’t afford to remake every sprint — written down precisely enough that design, engineering, and now models all read them the same way.

What follows is how that gets built: the foundations that decide whether a product feels considered or assembled, the architecture that lets it scale, the pipeline that keeps Figma and code from drifting apart, and the governance that keeps it alive after launch.

THE SAME SYSTEM · APPLIED IN PRODUCTION · LIVE IN CODE

The Warner Bros. Discovery content-sales tool I designed and built — running here on the real Water Tower tokens, with every elevation, radius, and color resolved from a variable rather than a value typed into a mockup. Select a few titles, or open the search bar. Play around with it!

[working title] Certified
AZ
Window
8/1/25 – 2/28/26
Client
Peacock
Media
Choose media
Main View 27,514
Filter Rating: G, PG-13
NameAvailabilityWindowRestrictions
0 selected Clear

Foundations — the part people feel

Water Tower — the design system for Warner Bros. Discovery's global content and streaming platforms.

Every system rests on a handful of decisions about color, type, and space. Get them wrong and no amount of governance rescues the result. Get them right and they do quiet work on every screen in the product. This is craft that happens to be systematic.

Color, in oklch

I build ramps in oklch rather than hex or HSL because it’s perceptually uniform: the step from 400 to 500 looks like the same size step on every hue. Ramps stay predictable, themes stay coherent, and contrast becomes something you calculate instead of eyeball.

Representative ramps

A few ramps up close — the same 50–950 structure across every hue.

Full system

Eight ramps — gold, orange, red, green, blue, indigo, violet, plus grayscale — each a full 50–950 scale with hex and oklch values on every step.

Type and space

A modular type scale and a spacing system built on one base unit. Every size and every gap resolves to a token, so vertical rhythm survives contact with a dozen product teams working in parallel.

Four families (base, title, display, mono), a full weight range, and a size scale from 10 to 72px — each
step a token in px and rem.

The scale

A modular scale from 10 to 72px — every step a token, in px and rem.

And the rest of the scale

Line-height and letter-spacing, tokenized to the same standard.

*These are 2 tokens examples out of 14 for each line-height and letter spacing*

Theming

One foundation, several expressions — light and dark, plus per-product theming so separate tools in a suite share a backbone without looking identical.

Accessibility, at the token level

Contrast compliance built into the token pairings rather than caught in review. If a combination isn’t accessible, it isn’t in the system.

Architecture — how it scales

A tiered taxonomy: primitives hold raw values, semantic tokens carry intent, component tokens bind that intent to specific parts. A component never reaches past its own tier to a raw value. That one rule is what lets you retheme an entire product by changing a single layer, and what stops one color decision from being re-litigated in forty places.

Naming as an interface

A structured grammar — component, variant, property, state — so a token’s name tells you what it’s for before you look it up. Names are an interface. Bad ones cost a team more than bad components do.

Components

Built with variants, auto-layout, and documented states from the start, then published as versioned shared libraries — so consuming teams pull from something predictable instead of copying it and quietly diverging.

From Figma to code, without the drift

Design and engineering come apart at the handoff, not the kickoff. The fix isn’t more documentation — it’s making the token pipeline the only path between the two, so changing a value in Figma arrives in the component library as a reviewable pull request rather than a message someone has to remember to act on.

At Warner Bros. Discovery, laying that groundwork for tokenized components in Storybook increased developer story-build efficiency by 50%.

See a prototype I built hands-on →

Governance that earns its keep

Governance has a bad name because it’s usually approval theatre. The useful kind is a short set of answers to predictable questions: who can contribute, how a proposal becomes a component, what bar it has to clear, and how everyone finds out it changed.

I define those, then spend most of the effort on adoption — documentation, office hours, and building alongside product teams instead of gatekeeping them. A system nobody adopts is just a very tidy Figma file.

Systems a machine can read

The next constraint on design systems isn’t human adoption — it’s machine legibility. Teams are pointing AI tooling at their systems and getting back output that looks plausible and quietly invents components that don’t exist. That isn’t a model problem. It’s a documentation problem: prose, screenshots, and implied rules are unreadable as constraints.

So I’ve been structuring token taxonomies and component documentation as machine-readable contracts — explicit schemas and metadata rather than narrative — so the same source that guides a designer can constrain a model. This is a developed point of view and a working approach rather than a shipped platform, pressure-tested daily against agentic tooling: Claude Code, Cursor, Figma MCP.

It’s the part of the practice I’m most interested in, and I think it’s where systems work is heading.

{
  "button": {
    "primary": {
      "bg": {
        "$type": "color",
        "$value": "wt-action-primary-bg",
        "$description": "Background for the primary (filled) button — the default, highest-emphasis call to action."
      },
      "bg-hover": {
        "$type": "color",
        "$value": "wt-action-primary-bg-hover",
        "$description": "Primary button background on hover."
      },
      "label": {
        "$type": "color",
        "$value": "wt-text-on-accent",
        "$description": "Label color intended for use on the primary accent background; pairing is contrast-checked at the semantic layer."
      },
      "border-color": {
        "$type": "color",
        "$value": "wt-action-primary-bg",
        "$description": "Border matches the fill so the primary button reads as a solid shape."
      },
      "border-width": {
        "$type": "dimension",
        "$value": "wt-stroke-width-0",
        "$description": "Primary button is borderless (filled)."
      }
    },
(Partial view)
*Tokens exported as a DTCG contract — `type‘/‘value`, semantic aliases resolving down the tiers. Structured as data rather than prose, the same source that tells a designer what `button/primary` is tells a build system — or an agent — how to build it correctly.*

In orbit

Water Tower is the system I built from nothing, and most of what’s above comes from it. These are the others — some I architected, some I extended, some I built for clients under someone else’s brand.

Global media & content licensing · Warner Bros. Discovery · 2025–2026

Water Tower — a multi-product system from zero

Architected the foundation for a suite of internal tools: token taxonomy, naming grammar, component libraries, theming, and documentation, with a token-to-Storybook pipeline underneath. Architected and piloted across multiple products, with adoption driven through documentation and hands-on partnership.

+50% developer story-build efficiency

Cloud infrastructure · internal tooling · AWS · 2022–2025

Contributing to a system at scale

Worked with the central design-system team to document interaction models, component patterns, accessibility guidelines, and usage standards — the connective work that drives adoption across teams who’ll never meet. Expanded the Figma system with interactive components and documentation alongside the UX Core team — working inside existing architecture and constraints rather than starting clean. Architected the foundation for a suite of internal tools: token taxonomy, naming grammar, component libraries, theming, and documentation, with a token-to-Storybook pipeline underneath. Architected and piloted across multiple products, with adoption driven through documentation and hands-on partnership.

Domain & commerce platform · GoDaddy, via Funsize · 2020–2022

Extending an established system

Expanded the Figma system with interactive components and documentation alongside the UX Core team — working inside existing architecture and constraints rather than starting clean. Architected the foundation for a suite of internal tools: token taxonomy, naming grammar, component libraries, theming, and documentation, with a token-to-Storybook pipeline underneath. Architected and piloted across multiple products, with adoption driven through documentation and hands-on partnership.

+20% development speed  ·  +15% UX

Enterprise hardware & services · Dell, via Funsize · 2020–2022

Systems and guidelines for an enterprise suite

Enhanced the enterprise design system and its guidelines, then led the redesign of transactional experiences built on top of it.

+25% consistency  ·  +20% UX metrics

Telecom, beverage & workspace brands · via Toi · 2017–2019

Client design systems, and the team that built them

Built design systems for Verizon, Red Bull, and WeWork while owning the client relationships and leading a team of four to eight designers. The practice starts here.

Explorations

Self-directed work — where I think the practice goes next.

Concept · not deployed

DS-Triage — AI-assisted system governance

What governance looks like when request volume outgrows the maintainer: automated intake, auto-triage to priority by a rules layer, an impact-versus-effort matrix, and a human approval gate before anything reaches a sprint.

* Note - WIP of the admin view
* Note - WIP of consumer/user view

Design system — requests

Swimlanes
* Note - WIP of a functional POC. Expand a request, filter the requests, and change the way you view it. Play around with it!