Tokenized Design System
Separating intent from implementation — so quality and compliance scale by default, not by repeated effort.
Context
As products multiply, so do one-off decisions — color, type, spacing, components, eventually rules — until consistency erodes and every team re-solves the same problems. The stakes climbed with each role: brand churn across dozens of Roku OEMs, fragmentation across a large Google org, and finally in-vehicle UI where inconsistency isn't off-brand — it's a distraction-safety problem governed by NHTSA and Android Auto.
My role
A decade-long thread across four roles, ownership growing each time: I helped build the first abstraction at Roku; at Google I co-invented Blox — the atomic design system with live specs and HTML export — and designed and shipped core features of its governance tool, Carbon; I architected the tokenized automotive system end-to-end at Amazon, and extended the thinking into AI behavior at 42dot. My constant collaborators were the engineers consuming the tokens and the teams adopting them — the system only counts if they use it.
Periodic Table of UI
An Atomic Design System
Composition
Approach
Three generations of one idea. Roku — an XML layer separating assets from implementation, so an OEM theme could swap without rewriting the UI. Google — JSON-defined vector assets driving shared SVG libraries and live specs, with Blox — which I co-invented — making components inspectable down to div/CSS with live specs and HTML export, and Carbon, whose roles & permissions, project settings, onboarding, and analytics I designed and shipped, giving the org a governed source of truth. Amazon — a shift from base to semantic tokens, so type, color, layout, and theming adapt through rules, and the key move: encoding distraction-safety constraints (NHTSA, Android Auto) into the components themselves, so teams inherit compliance from the parts they reuse instead of re-solving it.
Making it stick
A design system nobody is taught is just a document with opinions. At Google I treated adoption as its own product. I scripted and recorded a video curriculum for Blox, then taught it in person — more than seventy four-hour sessions, over a hundred and fifty designers — until the system stopped being a mandate and started being how the org worked. The receipts came back through 200+ surveys: 90% acceptance, 70% adoption. The lesson carried into every system since: the components are half the work. The other half is people, and that half doesn't ship in a repo.
The hard call
Compliance-by-default over local flexibility. Baking safety rules into components removes some team freedom — which is the point: in a safety-critical context, guaranteed compliance beats per-team latitude. The governance model drew that line on purpose — strict where safety lives, open everywhere else.
Outcome
At Google, Blox reached 150+ designers (90% acceptance, 70% adoption across 200+ surveys) and gave back the hours designers lost hunting for specs. At Amazon, compliant-by-default components produced a projected ~35% design-to-development efficiency gain in annual planning — and became the foundation for the windowing, global-surface, and embedded-AI systems that followed.
The fourth generation
Three generations of this idea were built inside companies — Roku's XML layer, Blox and Carbon at Google, the semantic token system at Amazon. In 2026 I built the fourth one alone: Component Studio, a product where the discipline itself is the product. Every component becomes a Passport — one canonical, structured record that design tools and codebases consume instead of owning. Sixty-one components render through a single tool-agnostic pipeline, pixel-proven against goldens; 450 tests; 45 recorded architecture decisions; a working publish path into Sketch. Ten years of running design systems for other people's platforms, finally pointed at the problem itself.