DESIGN SYSTEMS · PLATFORM · MULTI-FRAMEWORK · AI
Phenom Design System: Defining 'Ready' Across Frameworks
COMPANY
Phenom · HR Tech ·
~1,700 people
ROLE
Design System Lead
EXPERTISE
Tokens · Components · Governance
YEAR
2024 - Present
At Phenom, the design system had grown into a working library of components and Figma libraries - proof of strong cross-team investment in shared UI. The next step was giving it the foundations of a platform: a token architecture that could scale across frameworks, a definition of "ready" that everyone could agree on, and governance that made multi-framework delivery (Angular and React) and emerging AI-assisted workflows predictable.
The work focused on building those foundations: a three-layer token system (primitives, semantic, component), a readiness contract with explicit gates, and a parity model that aligned behavior across frameworks.
The matrix is the centerpiece of this case study - but it sits on top of token architecture, governance design, and a strong partnership between design and engineering.
Timeline
Started in 2024 with the readiness model. Still going - pattern layer and AI workflows are next.
Background
The Design System Lead role was created in response to a proposal outlining how the system could evolve from a working component library into a platform. The opportunity was to layer the missing foundations on top of what already worked: token architecture, multi-framework parity, and a shared definition of 'ready'.
The work was about building the foundations that turn a component library into a platform - a token architecture, a definition of "ready", and a parity model that aligned design and engineering across frameworks. The matrix is one of those foundations, and the one this case study focuses on.
System as a Platform
Treated the design system as a product, not a library. The distinction matters: a library ships components, and the consumer figures out the rest. A platform defines how those components behave, what they guarantee, and what they're accountable for - across designers, engineers, and product teams using them.
A Shared Definition of Ready
Defined what 'ready' meant, in writing. Five categories of gates: implementation, accessibility, API, enablement, composition. Each gate has explicit pass/fail criteria. One failed gate means the component isn't v1 - no averaging, no 'mostly ready'. The matrix turned readiness into a threshold and a shared standard across teams.
Multi-framework Parity
Treated Angular and React as two implementations of the same system, not two separate efforts. The work was about behavior - what the component does, how it handles focus, what tokens it consumes - not pixel-perfect alignment. Parity across frameworks meant the component felt the same to use, even if the code looked different.
Composition over Components
Recognized that components passing on their own didn't yet guarantee they'd work seamlessly when composed into a real pattern. Tested this by implementing part of the Table system in code - filters, saved views, bulk actions - which surfaced where the matrix could be extended. Added composition as the fifth gate category to capture those insights.
AI as Consequence
The same gates that protect designers and engineers also protect against AI amplifying the wrong things. As agent-driven workflows start entering design system work, governance designed for people extends naturally to tools. Early work has focused on making the system's specs readable for both humans and AI agents.
Cross-functional Partnership
Worked in close partnership with the Dev Lead. Adoption happened through clear documentation, internal sessions, and ongoing collaboration with product teams - not through mandate, but through shared understanding of the system's value.
The system was built around three foundations: a token architecture as the shared language between design and engineering, components built and tested for cross-framework parity, and a governance model that defined how the system evolves over time.
Token Architecture
Built a three-layer token system from the ground up: primitives for raw values, semantic tokens for roles like text/primary or bg/interactive, and component-specific tokens for tied behaviors. Tokens became the language design and engineering used to describe theming, parity, and behavior - before any component was built or shipped.
The token architecture is the shared language between design and engineering. Three layers - primitives at the bottom, components at the top — and a clear handoff between them.
Component System
Designed reusable components in Figma, fully aligned with the token architecture, and partnered with engineering to deliver them in Storybook across React and Angular. Each component is documented and accessible, available to both designers and engineers. Storybook serves as the single source of truth for engineers; Figma master serves the same purpose for designers.
The Phenom Design System component library - built across React and Angular, organized into Form, Buttons, Messages, and Misc.
Multi-framework Parity
Established cross-framework parity between React and Angular: shared token consumption, shared accessibility behaviors, shared API patterns. The two implementations could differ in framework-native idioms, but the behavior - what the component does and how it behaves under interaction - was identical across both.
A single component across two surfaces - Figma documentation for designers, auto-generated Storybook API for engineers. Same source of truth, same states, same token architecture.
Readiness Model & Governance
Introduced an explicit readiness model defining what 'v1 ready' means across five categories: implementation, accessibility, system & API, enablement, and composition. Hard-gated, threshold-based, and applied consistently across components. The model also defined how new components enter the system, how existing ones evolve, and how readiness is reviewed across teams.
Accessibility & Quality Foundation
Embedded accessibility into the readiness model from day one - keyboard navigation, focus management, contrast compliance, and screen reader support became non-negotiable gates rather than later additions. The same applied to visual QA, state coverage, and documentation completeness.
Effects and accessibility states are tokens too. Shadows define depth and elevation; focus rings define how the system looks when keyboard navigation takes over. Both are versioned, both are part of the system. In a system where 'ready' has a shared definition, accessibility can't live in someone's memory - it has to live in tokens.
AI & System Evolution
Started exploring how the readiness model extends into AI-assisted workflows - early work on machine-readable specifications and documentation that AI agents can read alongside humans. The system was designed to make this possible: predictable foundations matter more, not less, when components are consumed by tools as well as people.
Cursor agent generating React and Angular code that consumes the Phenom Design System's components, rendered live in the preview. Internal experiment - not production deployment.
The impact extended beyond components. The system became a platform - with a shared definition of 'ready', cross-framework parity, and a foundation built to scale into AI-assisted workflows.
Explicit Readiness Standard
Introduced the first explicit, written definition of 'v1 ready' in the system's history. Five categories of gates, applied consistently across components. Conversations about 'is this done?' became conversations about 'which gates are still open?'.
Shared Vocabulary Across Teams
The matrix gave design, engineering, and product the same words to talk about components - what's done, what's blocked, what's next. Disagreements about readiness moved from opinion to evidence: a specific gate, a specific reason.
Cross-framework Parity
React and Angular implementations now share the same tokens, the same accessibility behaviors, and the same component APIs. Framework-native idioms can differ, but the behavior - what the component does and how it responds - is identical across both.
Pattern Layer as Next Leverage
Strong components are now the baseline, not the destination. The Table system worked as a stress test: it showed where composition mattered more than component-level quality, and shaped the next phase of system development.
AI-Ready Foundation
The same readiness model that governs human use of the system also prepares it for agent-driven workflows. Predictable foundations and machine-readable specs mean the system is ready to be generated from, not just drawn from. Active exploration of AI-assisted workflows is underway.
The Next Phase
The readiness model is the foundation. The next phase is pattern adoption, AI-assisted workflows on top of governed foundations, and continued evolution of how the system serves cross-functional teams. The matrix made this trajectory possible by making 'ready' explicit, predictable, and shared.
The redesigned Candidates view in the Recruiter experience - product design using the Phenom Design System's Table, Bulk Action Bar, Filter Chips, and form components.
What this case demonstrates
Architecting design systems as platforms, not component libraries
Establishing governance models that scale consistently across multiple frameworks
Bridging design and engineering through token-driven workflows
Defining what 'ready' means for a multi-team, multi-framework system
Stress-testing systems under real implementation, not theoretical review
Preparing system foundations for AI-assisted and agent-driven workflows
Driving cultural change through artifacts, partnership, and clear communication