Pioneering an AI-native design system for JPMC Employee Assistant
August 2026 - present
[mockup of the component library webpage]
I helped build the design system behind JPMC Employee Assistant, extended it into an AI-readable system that enables product teams to turn real user scenarios into interactive prototypes with AI.
Overview
Problem
As JPMC Employee Assistant evolved, we needed a design system that could support a dynamic AI product across different components, interactions, modalities, and states.
At the same time, teams were beginning to use AI to prototype new experiences, but our AI tools had no understanding of how Employee Assistant was designed. Because JPMC restricts access to Figma MCP, they couldn't directly consume the design-system knowledge stored in our Figma libraries.
Solution
I worked on building the foundations, components, and interaction patterns behind Employee Assistant, then translated that system into structured rules that AI could understand and apply. This created a shared design language for both humans and AI, helping teams generate Employee Assistant experiences without repeatedly prompting every visual, component, and behavioral detail.
Impact
—
Time to create prototypes
XX%
Design system accuracy
XX
Adoption of the AI-native system
Context
Designing a system for an evolving AI product
Employee Assistant is an AI-powered experience that helps JPMC employees find information, complete tasks, and navigate services across the firm. As the product evolved, we needed more than a collection of reusable UI components. We needed a system that could define how Employee Assistant should look, behave, and respond across different contexts.
The interface is inherently dynamic. Experiences can shift between conversational and structured interactions, components can appear in different combinations depending on context, and the system needs to support different modalities, layouts, states, and responsive behaviors.
Rather than designing each experience independently, we needed to establish the underlying rules that could support many different Employee Assistant experiences.
JPMC Employee Assistant
Why it matters
A strong design system gives product teams a shared language for creating consistent experiences. But AI introduced a new opportunity. If we were already defining the rules that govern Employee Assistant, could we structure those rules so AI could understand and apply them too?
That would allow the design system to serve not only the designers and engineers building Employee Assistant, but also the AI tools helping teams explore what Employee Assistant could become.
The challenge
The next design-system consumer wasn't human
Traditional design systems are created primarily for designers and engineers. Foundations live in Figma, components are documented visually, usage guidelines explain when and how patterns should be applied. Designers interpret this information and translate it into experiences.
That model breaks down when the consumer is AI. JPMC restricts access to Figma MCP, preventing our AI tools from directly accessing our Figma libraries. They had no built-in understanding of our foundations, components, properties, states, interaction patterns, or usage rules.
AI could generate an interface, but it couldn't reliably generate Employee Assistant. Without that knowledge, designers would need to repeatedly describe everything, from typography, spacing, and layout to component properties, states, interactions, and behaviors, through prompts.
[Screenshot of Figma MCP and screenshot restriction]
This raised a different design-system question: "How might we create a system that both humans and AI can understand and use to build Employee Assistant experiences?"
My approach
Building the system, then teaching AI how to use it
Rather than treating AI enablement as a separate layer of documentation, I approached the problem as an extension of the design system itself. I broke the system into four interconnected layers:
Establish the foundations that govern how Employee Assistant looks and feels, including typography, color, spacing, sizing, elevation, grids, and responsive behavior and represent those decisions as explicit rules.
Create reusable Employee Assistant components with clearly defined anatomy, properties, variants, states, accessibility requirements, styling, and interaction behaviors.
Establish the relationships between components: how they are composed, how layouts respond, how states transition, and how recurring interaction patterns work across Employee Assistant.
Together, these layers created more than a visual reference. They created a system that defines what Employee Assistant is made of, how it behaves, and how those rules should be applied by both humans and AI.
Phase 1 — Foundations
Establishing a visual language humans and AI could share
I started with the foundations that give Employee Assistant its visual identity.
This included typography, color, spacing, sizing, border radius, elevation, grids, and layout rules.
Rather than treating these as isolated values, I defined the relationships and usage rules behind them, how spacing should respond to context, how hierarchy should be expressed, and how foundational decisions should propagate through components and layouts. I then represented these decisions as explicit, reusable instructions that AI could consistently interpret and apply.
The result was a foundation layer that could serve two consumers: designers using the system to make decisions and AI using the same rules to generate interfaces.
[Screenshot of the foundation tokens page in VS Code]
Phase 2 — Components
Creating reusable building blocks
With the foundations established, I worked on the components that make up Employee Assistant. A component is more than its appearance: its anatomy, properties, variants, states, interactions, accessibility requirements, and usage conventions all determine how it should behave within an experience. I defined these characteristics and structured components to inherit the foundations established in the previous layer.
I then translated that component logic into reusable AI building blocks.
This meant AI didn't just know how a component should look. It could understand which variants exist, how different states behave, how the component should be configured, and eventually when it should, or shouldn't be used.
The result was a reusable component architecture rather than a collection of AI-generated approximations.
[Screenshot of components overview page in VS Code]
Phase 3 — Patterns & Behaviors
Defining how the pieces become an experience
Accurate foundations and components still weren't enough. A prototype could visually resemble Employee Assistant while behaving nothing like the actual product.
The next layer therefore focused on the relationships between components: how they should be composed, how layouts respond to different contexts, how the interface changes after user actions, and how experiences transition between states. I defined recurring interaction patterns and behavioral rules across Employee Assistant, then translated those relationships into explicit instructions AI could apply.
This allowed the system to understand not only individual components, but how those components work together to form an Employee Assistant experience.
[Video recording of the Assistant control panel page, show the interactions of modality switch]
Phase 4 — AI-native system
From design-system documentation to executable design knowledge
Once the underlying design language was established, I focused on making it usable by AI. Traditional design-system documentation is optimized for humans. Designers can interpret visual examples, understand contextual guidance, and fill in gaps using experience and judgment.
AI needs something more explicit. I translated our foundations, components, patterns, and behaviors into structured instructions and reusable AI skills that captured both specifications and the rules governing how they should be applied.
Instead of relying on AI to infer Employee Assistant from screenshots, or asking designers to repeat the same instructions in every prompt, the design knowledge became part of the system itself. The design system was no longer only something people could reference. It became something AI could execute.
[Screenshot of a design skill, create a design skill for proper tokens and component usage?]
Real scenarios
From a user scenario to an interactive prototype
Once the system understood Employee Assistant's foundations, components, and behaviors, teams could change how they approached prototyping. Instead of starting with screens, designers and product owners could start with a scenario:
Who is the employee?
What are they trying to accomplish?
What should happen?
AI could then use the underlying system to determine the appropriate foundations, components, layouts, states, and behaviors and generate an interactive Employee Assistant prototype as a starting point. Teams could refine the experience through follow-up prompts without reconstructing the underlying design-system logic each time.
This shifted the workflow from:
Prompting interface
→
Prompting experiences
and from:
Constructing
→
Evaluating
→
Reconstructing
to:
Generating
→
Evaluating
→
Reconstructing
[Video recording of a real user flow, e.g. schedule OOO?]
Impact
Reducing the gap between the idea and the AI output
The biggest change wasn't simply how prototypes were built. It was how much design-system knowledge could become reusable infrastructure.
Instead of every designer repeatedly translating Employee Assistant standards into individual prototypes or repeatedly explaining those standards to AI, the system could carry that knowledge forward.
This created three opportunities:
Product teams can move from a scenario to an interactive experience with less manual prototype.
AI-generated experiences inherit the same foundations, components, and behavioral rules instead of relying on generic interface patterns or one-off prompts.
Shifting design systems from documentation to infrastructure
AI didn't remove the need for design thinking. It changed what the design system itself could do. Traditionally, a design system documents decisions so people can understand and reproduce them. By making those decisions machine-readable, the same system can increasingly help AI apply them.
That means designers spend less time reconstructing known patterns and more time on the work that still requires judgment: defining scenarios, evaluating interactions, identifying edge cases, and deciding whether an experience actually solves the right problem.
My role in the transformation
From designing experiences to teaching AI how to use it and enabling others to create them
My role spanned both sides of this transformation: I worked on the design system behind Employee Assistant, defining foundations, reusable components, interaction patterns, and behaviors that establish how the product should look and work.
I then extended that system for a new type of consumer: AI. I translated design decisions into machine-readable rules, created reusable AI component representations, encoded interaction and composition logic, and continuously tested the system against realistic Employee Assistant scenarios.
I also worked across design, product, engineering, and leadership to pressure-test the approach, identify where generated experiences broke down, and evolve both the design system and the AI infrastructure around it.
As the work matured, my role shifted from designing individual experiences to building the infrastructure that enables others to create them. Instead of only designing Employee Assistant experiences, I helped build the system that enables both people and AI to create them.