Systems Thinking at Scale

Design Systems · AI-Ready Foundations · Scalability

Design systems are the foundation every product is built on whether the team knows it or not. My work across three companies has been to make that foundation intentional: built from brand, structured for scale, and open enough to absorb whatever the product becomes next.

The challenge is never just building components. It's convincing a company to invest in infrastructure before they feel the pain of not having it and building something flexible enough to outlast the problem that prompted it. At YieldX there was nothing to start from. At eMed what existed was outdated and incomplete. At Iru the company had attempted two design systems before I arrived, both broke under the weight of a product that kept growing.

Across all three I made the same set of decisions starting from brand, establishing a 3-tier token architecture separating primitives from semantics from components, defining grid and breakpoint systems calibrated to the actual product, and building component libraries designed to absorb new patterns rather than resist them.

A strong design system foundation isn't overhead, it's the thing that makes everything built on top of it faster, more consistent, and easier to evolve. Three systems. Three companies. Each one still running.

200+ components unified across platforms

87% enterprise platform migrated to new system

First system built for AI-assisted frontend development

Every system I build is structured around 3 tiers. This separation is what makes theming possible, migration manageable, and AI tools accurate.

Tier 1: Primitives - Every color, size, spacing unit the system can produce. Never referenced directly in components. Green is a primitive. Success is not. That distinction is what makes theming work.

Tier 2: Semantic - Named by role, not value. What designers and engineers see and use daily. An AI agent reading a semantic token knows what to do. An agent reading a hex value guesses wrong at scale.

Tier 3: Components - Components reference semantic tokens only, never primitives directly. Swap the semantic layer and the components follow. White-label, rebrand, theme, handled at the token level without touching a single component.

Grid & Responsiveness - Breakpoints calibrated to the actual product, not copied from framework defaults. At Iru I defined 5 custom breakpoints that fit our actual viewport distribution.

Semantic Colors - Primitives never collide with semantic roles. Each token carries a documented purpose and WCAG contrast ratio.

Typography System - One source of truth. At YieldX, 7 type categories with separate scales for numbers, graphs, tables, and inputs, each tokenized.

Open Component Base - A minimal, intentional set of components covering the product today and what it's becoming. New patterns get absorbed, not bolted on.

No brand. No components. No design language. I started with the logo and typography, then built every token and component original to YieldX. Dark-first for data density. 9-step primitive color scales. Button token system covering 5 types. Typography across 7 categories. The system supported 5 interconnected applications and an acquisition.

Inherited an outdated, incomplete system. Rebuilt on Tailwind base with WCAG contrast ratios documented at every token level. Covered web, iOS, and the clinical proctor dashboard from one unified library.

Iru's design system history before I arrived was two broken attempts. I stabilized it in 3 months. Built a Shadcn-based bridge that unified the component base. That bridge is now 87% migrated across the platform. Pulse is the full vision, and a token engineer has been hired to bring it to production.

When I say "AI-ready design system" I mean something specific: a system so well-documented, so consistently named, and so thoroughly structured that you can give an AI agent a guardrail and trust that what it builds will stay true to the design language, without constant correction.

Three requirements: unambiguous token naming, Figma-code parity, and documented component intent.

Every system I've built has outlasted the problem that prompted it. At YieldX it supported an acquisition. At eMed it survived a platform pivot without starting over. At Iru it stabilized a product that had broken two design systems before I arrived. That's what I build. Not component libraries. Systems.