How I lead the AI4Design working group at JPMorgan Chase — teaching designers to integrate LLMs and Copilot into their daily practice through workshops, onboarding documentation, and 1:1 ramp-up support.
LLMs and GitHub Copilot were rolling out across JPMorgan, and the promise for design work was real — faster ideation, structured research plans, working prototypes from markdown specs. But the tools were arriving faster than the practice around them. Designers had access to LLM, DevGPT and GitHub Copilot, but no shared answers to the basic questions: where does this fit in my day? what's it actually for? what does "good" use look like?
Most of the existing AI guidance was written by and for engineers. It assumed comfort with the terminal, with prompt engineering as a discipline, with code as a first language. Designers were being onboarded into a workflow that hadn't been designed for them.
AI adoption in a design org isn't a tooling problem. It's a confidence problem. The barrier wasn't "can you use this?" — it was "is it for someone like me?" Without a designer-shaped onramp, most people would either bounce off or use the tools shallowly.
I saw this as a design problem in the most literal sense: the adoption experience itself needed to be designed — researched, documented, taught, and iterated on like any other product.
Before trying to teach anyone, I needed something worth teaching. I spent months integrating LLMs and Copilot into my own design practice — finding where they earned their place, where they didn't, and what the actual workflow looked like end-to-end.
The result was a six-stage pipeline I now use on most projects. Each stage has a specific job, a specific failure mode, and a specific reason the tool helps.
The biggest unlock wasn't any single stage. It was the continuity — having a defined workflow meant I stopped asking "should I use AI here?" and started asking "what does this stage need from it?"
Once the workflow stabilized for me, the question became: how do I make this transferable to designers who haven't yet found their footing with these tools? I founded the AI4Design working group as the answer with a few like-minded designers.
The working group is structured the way I'd structure any product with users on a learning curve: clear onramps for different starting points, low-friction support, and shared artifacts that improve as the community uses them.
The breakthrough wasn't finding the "right" answer — it was structuring a conversation where twelve teams could discover the answer together.
The onboarding documentation was the piece I spent the most time on. Most internal AI guides I'd seen failed designers in a specific way: they answered the wrong questions in the wrong order. So I rebuilt them from a designer's mental model first.
Midway through this work, GitHub Copilot access was pulled across the org. The end-to-end workflow broke at a critical stage. The pipeline now has a well-defined input process (LLM-assisted ideation and documentation) and a hosting destination (Atlas), but the middle step —turning specs into interactive prototypes— is now manual and slow. The speed and iteration gains the tool provided are gone.
I documented the impact rigorously and surfaced it as a business case — both because the program needs it back, and because the loss is itself a teaching moment about how thin the seam between "AI-assisted" and "AI-dependent" actually is.
AI4Design gave the design org a shared language for AI-assisted practice — a pipeline, a vocabulary, a place to ask questions, and a set of designer-shaped instructions for getting started. The outcome I care about most isn't a number; it's that designers who previously avoided these tools now reach for them as part of their normal day.
The clearest signal of success: designers sharing their own AI-assisted work back into the community.
The most useful frame I found was this: tool adoption inside an org is a product. It has users, a UX, an onboarding flow, and edge cases. Treating AI4Design that way — rather than as a training program or a memo — is what made it land. Designers recognized the shape of it because it was designed for them in the way they design for others.
I increasingly believe the line between "designer" and "designer who builds with AI" is going to dissolve the way the line between "designer" and "designer who works in Figma" did. AI4Design is my attempt to make that transition gentle — and to position the designers I work with on the right side of it.
AI is the most interesting thing happening in our craft, and the adoption question is wide open across the industry. The skills I built running AI4Design — designing onramps, writing for non-technical users, identifying what a tool earns its place doing — are the same skills that matter at companies building AI products from the inside. That's the work I want to do next.