Evolving the Design System Behind Seven Products
Role: Product Design Manager (player-coach, design leadership)
Ownership: Owned the design-system strategy and execution for Emperor UI.
Team: Junior Product Designer , Engineering Manager (stakeholder), Lead Software Engineer (Stakeholder)
Timeline: Q2 2026
Problem & Context
Problem Statement
Bold Penguin shipped product experiences across seven offerings, four design systems, and three tech stacks. Emperor UI existed, but it had fallen behind as the unifying layer, so teams shipped features in silos without a shared source of truth. As AI entered team workflows, generating new UI got dramatically cheaper while standardizing it did not, creating technical and design debt faster than a three-person design team could absorb. Users felt it too: each product surfaced AI assistance differently, so agents had to relearn how to interpret and trust the system every time they moved between tools.
The system needed an upgrade to drive consistency across the portfolio, give cross-functional teams a guide for building on-brand prototypes, and establish a foundation for shipping AI features that fit the system rather than working around it.
I synthesized product, technical, and user evidence to define how fragmentation across seven products was accelerating inconsistency, design debt, and user friction.
Opportunity Solution Tree
The desired outcome was to help teams ship consistent, accessible, and on-brand UI faster, addressing opportunities to align design with production, improve component discovery and product scoping, enable on-brand AI prototyping, and reduce dependence on designers.
I used an opportunity solution tree to connect team barriers to a unified design-to-code solution and identify the assumptions to validate before scaling.
The Solution Chosen to Pursue
Rebuild Emperor UI as a synchronized design-and-code system where Figma defines the contract, code implements it, and Storybook verifies it. Within the first phase of this effort, my goal was to make the official version of everything easy to find, obviously correct, and the only one available — so that using it becomes the path of least resistance instead of an act of discipline.
Success Metrics
- Parity is verified across the P0 component set, ensuring each coded implementation matches its Figma spec in Storybook and is fully documented.
- Eliminate all duplicate implementations of P0 primitives in production by converging on a single canonical version and deleting legacy alternatives.
- P0 components should have no hardcoded color, spacing, or typography values; all styling should derive from the token layer.
Build to learn phase
The audit revealed that token duplication wasn’t a discipline problem but a discoverability problem: with 52 of 115 semantic tokens unused, teams found it faster to create new tokens than locate existing ones. This shifted my focus from redesigning the system to improving its information architecture.
I audited 230 stylesheets, Git history, and the dependency graph, revealing that 176 of 223 components lived outside the design system, a high-churn mixin affected 13 components across five apps, and 52 of 115 semantic tokens were unused.
The key lesson was to complete the audit before seeking engineering alignment so the scale of the problem could strengthen the case for migration and governance.
I created a merge-triggered governance model that uses AI to identify design-system changes, flag Figma-to-code drift, and route each change through a traceable review process. Changes are promoted, kept experimental, or deprecated, with clear ownership and deadlines to prevent unresolved decisions from creating new debt.
Does this solve a real problem the people affected actually care about?
Can people actually run this?
Can this be built with what's available?
Does this fit the organization's model, goals, and constraints?
Yes, Designers feel system drift directly, while engineers must adopt small workflow changes to prevent its long-term costs from falling on design, users, and future teams.
The process is simple for engineers but risks overwhelming the system owner unless AI can turn changes into actionable judgments.
The governance model was technically straightforward to build and can be validated against past changes by measuring whether it missed design drift.
Without clear ownership, commitments, or review cadence, the design system’s long-term success depended unsustainably on a small design team.
As a player-coach, I aligned designers and engineers, audited the system to uncover component and token fragmentation, implemented foundational improvements, established a governance model, and validated its adoption, operational, technical, and organizational risks.
Core solution
The Emperor UI Governance Model and Emperor UI Sentinel provide a merge-triggered process that monitors shared design-system code, summarizes meaningful token, stylesheet, and component changes, and routes them into review before they become product-wide drift.
solution link
I designed a lightweight, code-aware governance model and created Emperor UI Sentinel to detect merged shared-system changes, summarize their impact, and guide design and engineering through reconciliation, lifecycle, and deprecation decisions.
Evidence of impact
- I audited and refined the 115 semantic tokens in the repository, consolidating them to 70—a 39% reduction in semantic-token complexity—while preserving nomenclature familiar to engineering teams to reduce the learning curve and support adoption.
- I adapted the 223 components in the repo to the atomic design system framework (atoms, molecules, organisms, pages), giving me the foundation to triage what we have and where it lives. Since we were building several new products in parallel, we decided as a team that we would eventually sunset some legacy products, which made it easier to leave certain components as-is while we built the future standard set.
- I created a lightweight governance model to catch and triage shared-system changes after they ship, including tokens, styles, and components. It gives design and engineering a traceable way to inspect each change, reconcile Figma with code, and decide whether it should be promoted to Emperor UI, remain experimental, or be deprecated with a migration path.
- I built a merge-triggered AI governance agent [Emperor UI Sentinel] that detects shared token, stylesheet, and component-library changes, summarizes their design-system impact, and sends linked review briefs for Figma/code reconciliation, promotion, or deprecation.
Evolving the Design System Behind Seven Products
Role: Product Design Manager (player-coach, design leadership)
Ownership: Owned the design-system strategy and execution for Emperor UI.
Team: Junior Product Designer , Engineering Manager (stakeholder), Lead Software Engineer (Stakeholder)
Timeline: Q2 2026
Problem & Context
Problem Statement
Bold Penguin shipped product experiences across seven offerings, four design systems, and three tech stacks. Emperor UI existed, but it had fallen behind as the unifying layer, so teams shipped features in silos without a shared source of truth. As AI entered team workflows, generating new UI got dramatically cheaper while standardizing it did not, creating technical and design debt faster than a three-person design team could absorb. Users felt it too: each product surfaced AI assistance differently, so agents had to relearn how to interpret and trust the system every time they moved between tools.
The system needed an upgrade to drive consistency across the portfolio, give cross-functional teams a guide for building on-brand prototypes, and establish a foundation for shipping AI features that fit the system rather than working around it.
I synthesized product, technical, and user evidence to define how fragmentation across seven products was accelerating inconsistency, design debt, and user friction.
Opportunity Solution Tree
The desired outcome was to help teams ship consistent, accessible, and on-brand UI faster, addressing opportunities to align design with production, improve component discovery and product scoping, enable on-brand AI prototyping, and reduce dependence on designers.
I used an opportunity solution tree to connect team barriers to a unified design-to-code solution and identify the assumptions to validate before scaling.
The Solution Chosen to Pursue
Rebuild Emperor UI as a synchronized design-and-code system where Figma defines the contract, code implements it, and Storybook verifies it. Within the first phase of this effort, my goal was to make the official version of everything easy to find, obviously correct, and the only one available — so that using it becomes the path of least resistance instead of an act of discipline.
Success Metrics
- Parity is verified across the P0 component set, ensuring each coded implementation matches its Figma spec in Storybook and is fully documented.
- Eliminate all duplicate implementations of P0 primitives in production by converging on a single canonical version and deleting legacy alternatives.
- P0 components should have no hardcoded color, spacing, or typography values; all styling should derive from the token layer.
Build to learn phase
The audit revealed that token duplication wasn’t a discipline problem but a discoverability problem: with 52 of 115 semantic tokens unused, teams found it faster to create new tokens than locate existing ones. This shifted my focus from redesigning the system to improving its information architecture.
I audited 230 stylesheets, Git history, and the dependency graph, revealing that 176 of 223 components lived outside the design system, a high-churn mixin affected 13 components across five apps, and 52 of 115 semantic tokens were unused.
The key lesson was to complete the audit before seeking engineering alignment so the scale of the problem could strengthen the case for migration and governance.
I created a merge-triggered governance model that uses AI to identify design-system changes, flag Figma-to-code drift, and route each change through a traceable review process. Changes are promoted, kept experimental, or deprecated, with clear ownership and deadlines to prevent unresolved decisions from creating new debt.
Does this solve a real problem the people affected actually care about?
Can people actually run this?
Can this be built with what's available?
Does this fit the organization's model, goals, and constraints?
Yes, Designers feel system drift directly, while engineers must adopt small workflow changes to prevent its long-term costs from falling on design, users, and future teams.
The process is simple for engineers but risks overwhelming the system owner unless AI can turn changes into actionable judgments.
The governance model was technically straightforward to build and can be validated against past changes by measuring whether it missed design drift.
Without clear ownership, commitments, or review cadence, the design system’s long-term success depended unsustainably on a small design team.
As a player-coach, I aligned designers and engineers, audited the system to uncover component and token fragmentation, implemented foundational improvements, established a governance model, and validated its adoption, operational, technical, and organizational risks.
Core solution
The Emperor UI Governance Model and Emperor UI Sentinel provide a merge-triggered process that monitors shared design-system code, summarizes meaningful token, stylesheet, and component changes, and routes them into review before they become product-wide drift.
solution link
I designed a lightweight, code-aware governance model and created Emperor UI Sentinel to detect merged shared-system changes, summarize their impact, and guide design and engineering through reconciliation, lifecycle, and deprecation decisions.
Evidence of impact
- I audited and refined the 115 semantic tokens in the repository, consolidating them to 70—a 39% reduction in semantic-token complexity—while preserving nomenclature familiar to engineering teams to reduce the learning curve and support adoption.
- I adapted the 223 components in the repo to the atomic design system framework (atoms, molecules, organisms, pages), giving me the foundation to triage what we have and where it lives. Since we were building several new products in parallel, we decided as a team that we would eventually sunset some legacy products, which made it easier to leave certain components as-is while we built the future standard set.
- I created a lightweight governance model to catch and triage shared-system changes after they ship, including tokens, styles, and components. It gives design and engineering a traceable way to inspect each change, reconcile Figma with code, and decide whether it should be promoted to Emperor UI, remain experimental, or be deprecated with a migration path.
- I built a merge-triggered AI governance agent [Emperor UI Sentinel] that detects shared token, stylesheet, and component-library changes, summarizes their design-system impact, and sends linked review briefs for Figma/code reconciliation, promotion, or deprecation.
Evolving the Design System Behind Seven Products
Role: Product Design Manager (player-coach, design leadership)
Ownership: Owned the design-system strategy and execution for Emperor UI.
Team: Junior Product Designer , Engineering Manager (stakeholder), Lead Software Engineer (Stakeholder)
Timeline: Q2 2026
Problem & Context
Problem Statement
Bold Penguin shipped product experiences across seven offerings, four design systems, and three tech stacks. Emperor UI existed, but it had fallen behind as the unifying layer, so teams shipped features in silos without a shared source of truth. As AI entered team workflows, generating new UI got dramatically cheaper while standardizing it did not, creating technical and design debt faster than a three-person design team could absorb. Users felt it too: each product surfaced AI assistance differently, so agents had to relearn how to interpret and trust the system every time they moved between tools.
The system needed an upgrade to drive consistency across the portfolio, give cross-functional teams a guide for building on-brand prototypes, and establish a foundation for shipping AI features that fit the system rather than working around it.
I synthesized product, technical, and user evidence to define how fragmentation across seven products was accelerating inconsistency, design debt, and user friction.
Opportunity Solution Tree
The desired outcome was to help teams ship consistent, accessible, and on-brand UI faster, addressing opportunities to align design with production, improve component discovery and product scoping, enable on-brand AI prototyping, and reduce dependence on designers.
I used an opportunity solution tree to connect team barriers to a unified design-to-code solution and identify the assumptions to validate before scaling.
The Solution Chosen to Pursue
Rebuild Emperor UI as a synchronized design-and-code system where Figma defines the contract, code implements it, and Storybook verifies it. Within the first phase of this effort, my goal was to make the official version of everything easy to find, obviously correct, and the only one available — so that using it becomes the path of least resistance instead of an act of discipline.
Success Metrics
- Parity is verified across the P0 component set, ensuring each coded implementation matches its Figma spec in Storybook and is fully documented.
- Eliminate all duplicate implementations of P0 primitives in production by converging on a single canonical version and deleting legacy alternatives.
- P0 components should have no hardcoded color, spacing, or typography values; all styling should derive from the token layer.
Build to learn phase
The audit revealed that token duplication wasn’t a discipline problem but a discoverability problem: with 52 of 115 semantic tokens unused, teams found it faster to create new tokens than locate existing ones. This shifted my focus from redesigning the system to improving its information architecture.
I audited 230 stylesheets, Git history, and the dependency graph, revealing that 176 of 223 components lived outside the design system, a high-churn mixin affected 13 components across five apps, and 52 of 115 semantic tokens were unused.
The key lesson was to complete the audit before seeking engineering alignment so the scale of the problem could strengthen the case for migration and governance.
I created a merge-triggered governance model that uses AI to identify design-system changes, flag Figma-to-code drift, and route each change through a traceable review process. Changes are promoted, kept experimental, or deprecated, with clear ownership and deadlines to prevent unresolved decisions from creating new debt.
Does this solve a real problem the people affected actually care about?
Can people actually run this?
Can this be built with what's available?
Does this fit the organization's model, goals, and constraints?
Yes, Designers feel system drift directly, while engineers must adopt small workflow changes to prevent its long-term costs from falling on design, users, and future teams.
The process is simple for engineers but risks overwhelming the system owner unless AI can turn changes into actionable judgments.
The governance model was technically straightforward to build and can be validated against past changes by measuring whether it missed design drift.
Without clear ownership, commitments, or review cadence, the design system’s long-term success depended unsustainably on a small design team.
As a player-coach, I aligned designers and engineers, audited the system to uncover component and token fragmentation, implemented foundational improvements, established a governance model, and validated its adoption, operational, technical, and organizational risks.
Core solution
The Emperor UI Governance Model and Emperor UI Sentinel provide a merge-triggered process that monitors shared design-system code, summarizes meaningful token, stylesheet, and component changes, and routes them into review before they become product-wide drift.
solution link
I designed a lightweight, code-aware governance model and created Emperor UI Sentinel to detect merged shared-system changes, summarize their impact, and guide design and engineering through reconciliation, lifecycle, and deprecation decisions.
Evidence of impact
- I audited and refined the 115 semantic tokens in the repository, consolidating them to 70—a 39% reduction in semantic-token complexity—while preserving nomenclature familiar to engineering teams to reduce the learning curve and support adoption.
- I adapted the 223 components in the repo to the atomic design system framework (atoms, molecules, organisms, pages), giving me the foundation to triage what we have and where it lives. Since we were building several new products in parallel, we decided as a team that we would eventually sunset some legacy products, which made it easier to leave certain components as-is while we built the future standard set.
- I created a lightweight governance model to catch and triage shared-system changes after they ship, including tokens, styles, and components. It gives design and engineering a traceable way to inspect each change, reconcile Figma with code, and decide whether it should be promoted to Emperor UI, remain experimental, or be deprecated with a migration path.
- I built a merge-triggered AI governance agent [Emperor UI Sentinel] that detects shared token, stylesheet, and component-library changes, summarizes their design-system impact, and sends linked review briefs for Figma/code reconciliation, promotion, or deprecation.