Pioneering an AI-native design system for JPMC Employee Assistant
August 2026 - present
I helped build the design system behind JPMC Employee Assistant, extended it into an AI-readable system so product teams could generate more accurate, interactive prototypes with AI.
Overview
Problem
As teams began using AI to prototype Employee Assistant experiences, AI had no understanding of our design system and couldn't directly access our Figma libraries. As a result, teams had to repeatedly prompt visual styles, components, layouts, and behaviors to get something that resembled the actual product.
Solution
I helped define Employee Assistant's foundations, components, and interaction patterns, then translated that design knowledge into structured rules AI could understand and apply. This created a shared design language for both humans and AI.
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. Unlike traditional applications, its interface is highly dynamic. Experiences can move between conversational and structured interactions, while components, layouts, and behaviors change based on context.
We needed a design system that could define not just how Employee Assistant looks, but how it behaves. At the same time, designers were increasingly using AI to prototype new ideas.
That introduced a new question: "What if the same design system could guide both people and AI?"
Current implementation of the JPMC Employee Assistant
The challenge
AI could generate an interface. It couldn't reliably generate Employee Assistant.
Traditional design systems are built for humans. Designers can browse Figma libraries, read documentation, interpret examples, and use their judgment to apply the right components and patterns.
AI couldn't do that. JPMC restricts access to Figma MCP, preventing our AI tools from directly accessing the design knowledge stored in our Figma libraries. Without that context, AI didn't know:
Which foundations to apply: typography, color, spacing, grids, elevation
Which components to use: properties, variants, states, accessibility
How experiences should behave: layouts, interactions, transitions, patterns
Designers had to repeatedly communicate this information through prompts, making generated experiences inconsistent and difficult to scale.
Organization-wide restrictions on Figma MCP and image uploads
My approach
Building the system, then making it understandable to AI
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 three interconnected layers:
Define the visual rules behind Employee Assistant and represent them explicitly enough for both designers and AI to apply.
Create reusable building blocks with clearly defined properties, variants, states, interactions, and usage guidance.
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.
Phase 1 — Foundations
Establishing a visual language
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.
But simply giving AI a list of values wasn't enough. I needed to define how those values should be applied, how spacing changes across contexts, how hierarchy is expressed, and how foundational decisions flow through components and layouts. I translated these decisions into explicit, reusable rules that both designers and AI could consistently apply.
The goal is to stop asking AI to guess what Employee Assistant should look like.
Foundation tokens for JPMC Employee Assistant
Phase 2 — Components
Creating reusable building blocks
Next, I worked on the components that make up Employee Assistant. Each component needed more than a visual specification. I defined its anatomy, properties, variants, states, interactions, accessibility, and usage.
I then translated this component logic into structured instructions for AI. Instead of approximating a component from a screenshot, AI could understand how it was constructed, which variants existed, how its states behaved, and how it should be configured.
This created a reusable component architecture rather than a collection of one-off AI recreations.
Component details for JPMC Employee Assistant
Phase 3 — Patterns & Behaviors
Defining how the pieces work together
Accurate components still don't create an accurate experience. A prototype could visually resemble Employee Assistant while behaving nothing like the real product. I therefore defined the relationships between components:
How components are composed: which elements belong together and in what hierarchy.
How layouts respond: how the experience adapts across modalities, grids, and interface states.
How interactions behave: what happens after user actions and how the interface transitions between states.
How recurring patterns work: common Employee Assistant behaviors that should remain consistent across experiences.
I then translated these foundations, component rules, and behavioral patterns into structured AI-readable instructions. Instead of repeatedly explaining the design system through prompts, AI could reference the same underlying rules when generating new experiences.
Guidelines and patterns for components
The shift:
Before:
AI tries to imitate Employee Assistant.
After:
AI generates from the rules behind Employee Assistant.
Real scenarios
From prompting interfaces to prompting experiences
Once AI understood the underlying system, teams no longer needed to start by describing the interface. They could start with the problem:
Who is the employee?
What are they trying to accomplish?
What should happen?
For example: "Create an Employee Assistant experience for an employee scheduling time away from work."
AI could use the underlying foundations, components, and behavioral rules to generate an interactive prototype as a starting point. Designers could then evaluate the experience, adjust the scenario, and iterate through follow-up prompts.
This shifted the workflow from:
Construct
→
Connect
→
Evaluate
→
Reconstruct
to:
Generate
→
Evaluate
→
Iterate
Create an OOO user flow through prompting
Giving teams control and visibility
Prototype controls — Configure without prompting
Not every design decision needs to be communicated through a prompt. I created a control panel that lets teams directly configure common prototype settings such as modality, theme, navigation, and grid layout. This gives teams more predictable control over the experience while AI handles the underlying implementation.
Control panel for JPMC Employee Assistant
Design library — Explore the system behind the experience
I also created an explorable library that brings Employee Assistant's foundations, components, properties, behaviors, and usage guidance into one place. Teams can understand how the system works, reference existing patterns, and see the same design rules that guide AI-generated experiences.
Component & foundation library for JPMC Employee Assistant
Impact
Reducing the gap between an idea and a testable experience
The biggest change wasn't simply generating prototypes faster. It was turning repeated design decisions into reusable infrastructure.
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 building the system behind them
My role spanned both sides of the work. I helped build the design system behind Employee Assistant: Defining foundations, reusable components, interaction patterns, and behaviors.
I then extended that work to AI, translating design decisions into structured, machine-readable rules and testing them against realistic Employee Assistant scenarios. I worked with designers, product partners, engineers, and leadership to identify where generated experiences broke down and continuously refine the system.
The project changed the level at which I was designing: Instead of only designing individual experiences, I was building the system that helps others create them.