In Progress
Building a Unified AI Pattern Library for Enterprise AI
Leading the creation of UXD PepsiCo's AI experience framework - a shared language for designing AI across five product types and multiple teams.
Leading the creation of UXD PepsiCo's AI experience framework - a shared language for designing AI across five product types and multiple teams.
PepsiCo's Supply Chain and Procurement teams were building AI-powered products at an accelerating pace, but every team was designing AI experiences independently. There were no shared patterns, no common vocabulary, and no consistency between how AI surfaced insights in one tool versus another.
The result: users moving between products encountered different interaction models for fundamentally similar AI behaviors. Leadership wanted to scale AI faster, but quality and coherence couldn't keep up with the pace of delivery.
How do you create a shared design language for AI experiences when no two product teams are solving the same problem, but their users expect the same level of clarity?
I lead a small team of 3–5 designers to build the library, managing timelines and deliverables to meet a defined deadline. After finalizing the five AI experience interaction patterns, we reached out to PepsiCo's Peacock design system team to co-create the component-level implementation, turning our pattern definitions into formal design system assets.
Through a combination of external research, internal product audits, and team workshops, we identified five distinct types of AI experiences across PepsiCo's procurement and supply chain products. These became the organizing structure for the entire library.
Each experience type contains patterns that define how AI should behave, communicate, and surface information within that context. Patterns are organized by experience type so teams can quickly find what's relevant to the product they're building.
This wasn't a top-down mandate. The library grew out of work the team was already doing: a shared recognition that we were solving the same AI interaction problems in isolation. Here's how we built it:
We studied published AI pattern systems, design guidelines, and principles from across the industry, identifying what existed, what was emerging as best practice, and where gaps remained for enterprise-specific use cases.
We audited PepsiCo's existing AI-powered products to catalog how each team was currently handling AI interactions, surfacing inconsistencies and identifying patterns that were already working well.
We brought the research together through working sessions, synthesizing external best practices with internal realities to define the five experience types and their associated patterns.
We built a wiki with guidelines and examples for each pattern, structured so any designer on the team can find, understand, and apply a pattern without needing to consult the person who created it.
We reached out to PepsiCo's Peacock design system team to formalize our patterns into proper design system components. Conversational AI shipped as a coded Peacock component, AI Chat, and is now available to teams across PepsiCo. We work through a mix of sync design reviews and async feedback via Figma and Teams to keep momentum.
Each pattern in the library follows a consistent three-section page structure designed for quick comprehension and practical application:
What the pattern is, when to use it, and which AI experience types it applies to.
A visual breakdown of the pattern's components with annotated examples showing different states.
Do/don't guidance grounded in real product scenarios, not abstract rules.
Pattern page screenshot available upon request
Conversational AI went all the way from wiki page to shipped design system component. Here's how it got there.
Chat was the AI experience teams were shipping the most, and the one most likely to drift. One live supply chain tool was chat-only. An earlier proof of concept had richer pieces like source citations, feedback, and insights that never made it to production. Same behavior, two very different implementations. If we were going to prove the library could create consistency, this was the place to start.
Our first anatomy was modeled on the live chat tool. It was a reasonable starting point but too thin to stand in for every team's needs. So we widened it: we pulled in what the proof of concept had gotten right, filled gaps using our external research, and defined the full set of states a conversation moves through, from the empty landing state to loading to a finished response.
Peacock was built for forms, tables, and dashboards. Chat broke some of those assumptions. There was no visual language for "the model is thinking," no container built for a response that mixes text with a table or chart, and no way to signal how confident an answer is. Instead of waiting for Peacock to solve all of that, we proposed a slot-based model. Peacock provides the structural shell and tokens, and the pattern defines what loads into the slot. You can see this in the shipped component, where a rich content slot sits right inside the AI message.
Working closely with the Peacock team surfaced a question nobody had answered: who owns behavior and who owns visuals? We made it explicit with a two-layer model. UXD owns the pattern guidance (purpose, behavior, principles). Peacock owns the component spec (anatomy, variants, tokens, code). We brought it to the Peacock team as a way of formalizing how we were already working together, not as a handoff.
When the first Peacock implementation came back, I consolidated my team's Figma feedback around three questions: Does it keep the intent of the pattern? Does it hold up visually? Does it behave the way people expect AI products to behave? A side-by-side audit across the landing, loading, and response states caught places where the build had drifted from the spec, including how the "thinking" state was shown, how suggested prompts appeared, and feedback flows that hadn't been documented yet.
AI Chat is now the first entry in Peacock's Patterns section. It's built from composable pieces (user and AI messages, sources, suggestions, header and footer utilities, and the rich content slot), so a team building a new AI tool can pull in a tested chat experience instead of designing one from scratch.
The AI Pattern Library isn't a standalone artifact. It's a foundation layer. The patterns we've defined are already informing active product work within the Supply Chain UXD team, including AI-powered should-cost modeling experiences that introduce AI insights, copilot-style assistance, and automated scenario creation into an existing procurement workflow.
This connection from pattern library to product design is intentional: patterns are validated through real product application, and product teams contribute learnings back to the library. With Conversational AI now shipped as a Peacock component and rolling out to product teams beyond Supply Chain UXD, the library is moving from a team-level reference into shared infrastructure that can scale across PepsiCo's AI products.
Research & definition: External research, internal audits, experience type taxonomy
Pattern documentation: Wiki with guidelines, examples, and page structure
Conversational AI in Peacock: First pattern shipped as a coded design system component (AI Chat)
Broader adoption: Rolling out beyond Supply Chain UXD to other product teams
Leading through structure, not authority. Managing a team toward a deadline when the work is ambiguous requires creating clarity, which means defining what "done" looks like before anyone can design toward it. My role was less about making design decisions and more about creating the conditions for the team to make good ones together.
AI patterns are a moving target. Unlike traditional UI patterns that stabilize over time, AI interaction patterns are still emerging industry-wide. Building a library now means accepting that it will evolve and designing the system to accommodate that evolution rather than resist it.
The bridge between pattern and system is where it gets real. Defining patterns in a wiki was one thing. Now that the design system team is actively building Peacock components from our specs, the work has shifted from defining what patterns should be to collaborating on how they get built: reviewing implementations, giving feedback, and making sure the intent behind each pattern survives the translation into reusable components.
Domain expertise compounds. My earlier work designing PepsiCo's manual should-cost modeling tool gave me procurement fluency that directly shaped how I think about AI patterns in this space. You can't design useful AI experiences without understanding what users were doing before AI showed up.