Systems Thinking at Scale
Design Systems
AI-Ready Foundations
Scalability
Systems Thinking at Scale
Design Systems
AI-Ready Foundations
Scalability
Systems Thinking at Scale
Design Systems
AI-Ready Foundations
Scalability
Summary
MISSION
MISSION
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.
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.
CHALLENGE
CHALLENGE
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. Developers were maintaining components in three places simultaneously.
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. Developers were maintaining components in three places simultaneously.
MY CONTRIBUTION
MY CONTRIBUTION
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. At Iru specifically: I stabilized a fractured system in 3 months with a Shadcn bridge that unified what developers were maintaining in three places, then used that foundation to architect Pulse, the full vision with a token engineer now hired to bring it to production.
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. At Iru specifically: I stabilized a fractured system in 3 months with a Shadcn bridge that unified what developers were maintaining in three places, then used that foundation to architect Pulse, the full vision with a token engineer now hired to bring it to production.
CLIENT & ROLE
CLIENT & ROLE
Global
Company
Florida
Location
2019 - Present
Duration
Sr. Product designer, Design Manager
Role
Figma / Shadcn Storybook / Cursor Claude / Tailwind
Tools
Systems foundations for the future
Service
KEY OUTCOME
KEY OUTCOME
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. Each one made the next version of the product possible without starting over.
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. Each one made the next version of the product possible without starting over.
3
3
Systems built for FinTech HealthTech, SaaS
Systems built for FinTech HealthTech, SaaS
200+
200+
Components unified across platforms
Components unified across platforms
87%
87%
Enterprise platform migrated to new system
Enterprise platform migrated to new system
AI
AI
First system for AI-assisted frontend development
First system for AI-assisted frontend development
Starting point
Starting point
DISCOVERY
DISCOVERY
Before I open Figma I ask one question: what does this company actually need its design system to do in two years, not today? A system built only for the product as it exists will break the moment the product evolves. Iru proved this twice before I got there.
Brand is always the starting point. Every decision, color, typography, spacing, component shape should trace back to brand identity and market position. If there's no brand yet, that's where we start. If a structural base like Shadcn makes sense, I'll use it but as a foundation, never as a substitute for the thinking that determines what gets built on top of it.
Before I open Figma I ask one question: what does this company actually need its design system to do in two years, not today? A system built only for the product as it exists will break the moment the product evolves. Iru proved this twice before I got there.
Brand is always the starting point. Every decision, color, typography, spacing, component shape should trace back to brand identity and market position. If there's no brand yet, that's where we start. If a structural base like Shadcn makes sense, I'll use it but as a foundation, never as a substitute for the thinking that determines what gets built on top of it.
QUESTION 1
Build from scratch or migrate?
From scratch: start with brand, choose a structural base if appropriate, build to scale immediately new products evolve fast. Migration: understand whether the existing system is holistic first. If not, get it there before improving it. Consistency before enhancement. Always.
QUESTION 2
Is it open?
Can new components be absorbed without breaking what already exists? Can new surfaces use the same tokens? Can a designer, engineer, or AI agent pick it up and stay consistent without constant correction? If not, the system isn't done.
Insight: "A closed system is a deliverable. An open system is infrastructure. Every system I build is designed to absorb new components, new styles, and new product surfaces without rebuilding the foundation. The test: when something new is needed, does the system make it easy or make it hard?"
Insight: Fixed income wasn’t inaccessible because of the financial product, it was inaccessible because of the experience layer.
This reframed our ambition: design a modern operating system for fixed-income portfolio construction.
The Architecture
The Architecture
DISCOVERY
DISCOVERY
Every system I build is structured around 3 tiers. This separation is what makes theming possible, migration manageable, and AI tools accurate. When tiers collapse into each other when primitives are used directly in components, or when semantic names describe values instead of roles the system becomes brittle and hard to evolve.
Every system I build is structured around 3 tiers. This separation is what makes theming possible, migration manageable, and AI tools accurate. When tiers collapse into each other when primitives are used directly in components, or when semantic names describe values instead of roles the system becomes brittle and hard to evolve.
Raw values
yx.base.color.dark.brand.primary
#015CFF
Global.Neutral.900
#070707
Primitives
TIER 1
very 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.
Role-based token
$foreground-success
$background-destructive
$border-info
$background-brand-action
Semantic
TIER 2
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 and guesses wrong at scale.
Semantic references only
yx.base.color.dark.button
.primary.background
$background-brand-action
→ Button CTA
Components
TIER 3
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.
4 layers every system covers
4 layers every system covers
GRID & RESPONSIVENESS
GRID & RESPONSIVENESS
Breakpoints calibrated to the actual product, not copied from framework defaults. Column structures, gutter widths, and margin rules documented as a system, not guessed per screen. At Iru I defined 5 custom breakpoints that fit our actual viewport distribution. The incoming VP of Design is backing them platform-wide.
Breakpoints calibrated to the actual product, not copied from framework defaults. Column structures, gutter widths, and margin rules documented as a system, not guessed per screen. At Iru I defined 5 custom breakpoints that fit our actual viewport distribution. The incoming VP of Design is backing them platform-wide.
SEMANTIC COLORS
SEMANTIC COLORS
Primitives never collide with semantic roles. Each token carries a documented purpose and WCAG contrast ratio. At eMed this was clinically non-negotiable. At YieldX it was financially necessary 10-color graph palette, 5 background levels, all documented with semantic intent. It should be non-negotiable everywhere.
Primitives never collide with semantic roles. Each token carries a documented purpose and WCAG contrast ratio. At eMed this was clinically non-negotiable. At YieldX it was financially necessary 10-color graph palette, 5 background levels, all documented with semantic intent. It should be non-negotiable everywhere.
TYPOGRAPHY SYSTEM
TYPOGRAPHY SYSTEM
One source of truth. At YieldX, 7 type categories with separate scales for numbers, graphs, tables, and inputs, each tokenized. At Iru there were 3 sources of truth before I consolidated them. Scanability and hierarchy are impossible to enforce from multiple places simultaneously.
One source of truth. At YieldX, 7 type categories with separate scales for numbers, graphs, tables, and inputs, each tokenized. At Iru there were 3 sources of truth before I consolidated them. Scanability and hierarchy are impossible to enforce from multiple places simultaneously.
OPEN COMPONENT BASE
OPEN COMPONENT BASE
A minimal, intentional set of components covering the product today and what it's becoming. No speculative components. Every component earns its place across multiple surfaces. New patterns get absorbed, not bolted on. At eMed the camera widget and self-attestation pattern did exactly this. Built to solve a problem, absorbed into the system, still running two years later.
A minimal, intentional set of components covering the product today and what it's becoming. No speculative components. Every component earns its place across multiple surfaces. New patterns get absorbed, not bolted on. At eMed the camera widget and self-attestation pattern did exactly this. Built to solve a problem, absorbed into the system, still running two years later.
The work
The work
FRAMING
FRAMING
The same thinking applied to three completely different starting points. The case studies earlier in this portfolio show what was built on top of each system. This is the blueprint underneath all of it.
The same thinking applied to three completely different starting points. The case studies earlier in this portfolio show what was built on top of each system. This is the blueprint underneath all of it.
YIELDX • 2019 - 2021 • BUILT FROM NOTHING
YIELDX • 2019 - 2021 • BUILT FROM NOTHING
No brand. No components. No design language. I started with the logo and typography establishing the visual identity the system would grow from, then built every token and component original to YieldX. Dark-first for data density. 9-step primitive color scales including a separate 10-color graph palette and 5 layered background levels for hierarchy in dense financial interfaces. Button token system covering 5 types with every interactive state documented. Typography across 7 categories; headings, text, numbers, inputs, buttons, tables, graphs, each tokenized. Collaborated with engineering on Storybook for white-label deployments. The system supported 5 interconnected applications and an acquisition.
No brand. No components. No design language. I started with the logo and typography establishing the visual identity the system would grow from, then built every token and component original to YieldX. Dark-first for data density. 9-step primitive color scales including a separate 10-color graph palette and 5 layered background levels for hierarchy in dense financial interfaces. Button token system covering 5 types with every interactive state documented. Typography across 7 categories; headings, text, numbers, inputs, buttons, tables, graphs, each tokenized. Collaborated with engineering on Storybook for white-label deployments. The system supported 5 interconnected applications and an acquisition.
EMED • 2021 - 2024 • REBILT INDER CLINICAL CONSTRAINT
EMED • 2021 - 2024 • REBILT INDER CLINICAL CONSTRAINT
Inherited an outdated, incomplete system. Rebuilt on Tailwind base with WCAG contrast ratios documented at every token level, clinical requirements made accessibility non-negotiable by default, not by choice. Covered web, iOS, and the clinical proctor dashboard from one unified library. The most important design system moment at eMed wasn't a component I planned. The self-attestation widget and camera widget were built from scratch to solve clinical UX problems, then absorbed into the system when we recognized they were reusable patterns. Both carried into the GLP-1 platform two years later without modification. That's what an open system does.
Inherited an outdated, incomplete system. Rebuilt on Tailwind base with WCAG contrast ratios documented at every token level, clinical requirements made accessibility non-negotiable by default, not by choice. Covered web, iOS, and the clinical proctor dashboard from one unified library. The most important design system moment at eMed wasn't a component I planned. The self-attestation widget and camera widget were built from scratch to solve clinical UX problems, then absorbed into the system when we recognized they were reusable patterns. Both carried into the GLP-1 platform two years later without modification. That's what an open system does.
IRU • 2024 - PRESENT • THREE ATTEMPTS, ONE VERISON
IRU • 2024 - PRESENT • THREE ATTEMPTS, ONE VERISON
Iru's design system history before I arrived was two broken attempts. Bumblebee, the company's first system, built at launch, too simple to survive growth. Nectar, a rebuild that was never fully thought through. By the time I joined, Nectar had fractured into two parallel systems and developers were maintaining components in three separate places simultaneously.
I stabilized it in 3 months. Built a Shadcn-based bridge that unified the component base, gave developers one place to work from, and looked enough like Nectar that no user would notice the change. That bridge is now 87% migrated across the platform.
Pulse is the full vision. The semantic token architecture with proper foreground, background, border, and chart token layers. AI gradient tokens. Alpha transparency scales for component interaction states. Refined breakpoints. A typography system with one source of truth. I started Pulse as my own project, now the VP of Design is backing it and a token engineer has been hired to bring it to production. The migration to the Shadcn bridge is what makes Pulse a smooth transition rather than another painful rebuild.
Iru's design system history before I arrived was two broken attempts. Bumblebee, the company's first system, built at launch, too simple to survive growth. Nectar, a rebuild that was never fully thought through. By the time I joined, Nectar had fractured into two parallel systems and developers were maintaining components in three separate places simultaneously.
I stabilized it in 3 months. Built a Shadcn-based bridge that unified the component base, gave developers one place to work from, and looked enough like Nectar that no user would notice the change. That bridge is now 87% migrated across the platform.
Pulse is the full vision. The semantic token architecture with proper foreground, background, border, and chart token layers. AI gradient tokens. Alpha transparency scales for component interaction states. Refined breakpoints. A typography system with one source of truth. I started Pulse as my own project, now the VP of Design is backing it and a token engineer has been hired to bring it to production. The migration to the Shadcn bridge is what makes Pulse a smooth transition rather than another painful rebuild.
Design systems & AI
Design systems & AI
FRAMING
FRAMING
When I say "AI-ready design system" I don't mean automated handoff or code generation. I mean something more specific and more useful: 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.
At Iru the guardrail is concrete: a skill built into the agent that says "don't move away from the connected design system if you think you need to, ask before you do." With MCP connections to Figma and Storybook, the agent can see the actual components, read the actual token names, and check its work against the actual system in real time. The result isn't perfect production code it's a frontend prototype with the right sizes, the right colors, the right spacing, the right components. No guessing. Developers start from complete information instead of from zero.
This only works because the system underneath it is thorough. Token naming is consistent. Component intent is documented. Typography comes from one source. The grid is defined. When any of those things are ambiguous the agent makes mistakes. When they're clear the agent stays consistent. The system is the guardrail. The AI is the tool.
When I say "AI-ready design system" I don't mean automated handoff or code generation. I mean something more specific and more useful: 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.
At Iru the guardrail is concrete: a skill built into the agent that says "don't move away from the connected design system if you think you need to, ask before you do." With MCP connections to Figma and Storybook, the agent can see the actual components, read the actual token names, and check its work against the actual system in real time. The result isn't perfect production code it's a frontend prototype with the right sizes, the right colors, the right spacing, the right components. No guessing. Developers start from complete information instead of from zero.
This only works because the system underneath it is thorough. Token naming is consistent. Component intent is documented. Typography comes from one source. The grid is defined. When any of those things are ambiguous the agent makes mistakes. When they're clear the agent stays consistent. The system is the guardrail. The AI is the tool.
AI SYSTME 3 REQUIREMENTS
AI SYSTME 3 REQUIREMENTS
Unambiguous token naming
Semantic tokens named by role, not value. $foreground-success not #44b556. $background-destructive not #D61414. An agent reading role-based names knows what to do. An agent reading hex values guesses and guesses wrong across an entire component tree.
Figma-code parity
Component names in Figma match component names in Storybook. When they don't, the agent can't connect what it sees in the design to what exists in the codebase. At Iru this is the work still in progress, 87% Nectar migration means 87% parity. Pulse will complete it.
Documented component intent
Not just what a component looks like what it's for. Banner vs callout vs toast: all three notify the user, all three look similar, all three have different rules for when and how to use them. An agent without that documentation picks one and applies it everywhere. That's a system problem, not an AI problem.
Reflection
Reflection
CLOSING
CLOSING
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 and it's now the foundation for Pulse, the version that should have existed from the start.
None of those outcomes were the brief. All of them required the same thing: a foundation built to last longer than today's product, open enough to absorb what comes next, and consistent enough that anyone designer, engineer, or AI agent can build on top of it without guessing.
That's what I build. Not component libraries. Systems.
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 and it's now the foundation for Pulse, the version that should have existed from the start.
None of those outcomes were the brief. All of them required the same thing: a foundation built to last longer than today's product, open enough to absorb what comes next, and consistent enough that anyone designer, engineer, or AI agent can build on top of it without guessing.
That's what I build. Not component libraries. Systems.