How I got my design org actually using AI
I didn't wait for an AI strategy. Three times I spotted something missing, took it to leadership, drove it from proof of concept to required workflow, and trained the people using it. That's a content-design agent, a shared knowledge base, and training across the org.
The gap
Three problems, all at once. Designers had no shared AI tool they could trust and build on. The org's knowledge was scattered across files and wikis, and nobody was maintaining it. And there was no real way for people to learn how to use any of it.
Fixing one would have helped. Fixing all three is what got people actually using AI in their day-to-day work.
Content-design agent
Everything content designers needed was spread across Figma files, wikis, and email threads. To get a decent answer from an AI assistant, you had to rebuild all that context every time.
The agent was my idea, and I built the foundation: the files that gave it structure, the content, how it's organized, and links between things that had never been connected. I was one of the first people in the org, and maybe the company, to set up content-design guidance this way.
I shared it with the other content designers, got them on board, and trained them to add to it. I presented it at an internal design showcase. My work was the vast majority of the first release, and of the foundation as it grew. Hundreds of designers across the org use it now, and PMs use it for content design and accessibility too.
Scattered content
- Figma files
- Wikis
- Email threads
- Rebuilt from scratch each time
One structured agent
- Foundational files
- Connected content
- Reusable by hundreds
- Content designers trained to add to it
Knowledge base
The knowledge base had stalled. Years of design knowledge sat in a system nobody was adding to or maintaining.
I took the problem to a senior leader in the design org, who connected me with the design manager overseeing it. With that manager and a small v-team, I defined the approach, built the proof of concept, and pushed it up the org. VPs liked it, and it became a full initiative.
Now the KB is required. Every designer in the org is expected to contribute. Once we got it to general availability, I took on the governance plan: how people submit, review, improve, merge, and close contributions and gap logs.
I designed the whole process. That includes entry types and templates, a review rubric, workflows for contributors and reviewers, triage, who merges what, and how we bring in subject-matter experts when there's a gap nobody can fill. I also built skills and prompts in the repo that walk people through it while they're doing the work.
I piloted it with a small group of reviewers, took their feedback, and fixed the process and the repo before rolling it out wider. I trained reviewers on the standard. I worked with principal design managers, DesignOps, and the owners of the broader design repo, where the KB is a core part of the org's AI strategy.
I went from helping launch the KB to owning how contributions and quality work. I still run the process and keep adjusting it as new cases come up.
- 01SubmitUse a defined entry type and template
- 02TriageRoute contributions and gap logs to reviewers
- 03ReviewApply the shared quality rubric
- 04ImproveResolve feedback and partner with SMEs
- 05Merge or closePublish trusted knowledge or resolve the log
Put the help where the work happens
A process only works if people can follow it. We looked at office hours, regular support sessions, and a library of training videos. Those would help, but they all live somewhere other than where people are actually contributing or reviewing.
I pushed for putting skills, workflows, and prompts right in the repo, backed up by the org channel we already had. People can ask questions where everyone already hangs out, or set up time for something specific. The repo gives the same guidance every time.
That way it doesn't depend on a recurring meeting or on me repeating myself. And when the process changes, we update the guidance in one place.
How this connects to my design repos
The agent and the KB are part of a bigger org-wide platform that lots of teams have added to. Together they give the org shared content guidance, organized knowledge, and context about the work we actually do.
The AI design repo I built for my business group plugs into that platform. It uses the KB, the agent, and other org tools instead of rebuilding them. That's how org-level work ends up being useful to a single team.
Training across the org
Building something and getting people to use it are two different jobs. I did both.
I'm one of the main AI trainers in my design org. I cover content design, the knowledge base, accessibility, gathering context, and research, for design managers and ICs. I don't just walk through tools. I teach when and how to use AI responsibly in the work people already do.
Some of that is formal sessions. Some is demos. When VPs came to see what the design team was doing with AI, I built those demos.
What required means
All three are now a required part of how the org works. That didn't happen because leadership mandated tools. It happened because the tools were useful, the KB was maintained, and people knew how to use both. I drove all three.
What I learned
The agent, the KB, and the training are all useful. But what made them stick was doing the same thing each time: find the gap, get support, do the work, teach it.
This kind of work doesn't show up in a job title. It shows up in how the org works.