index

Support Was Scaling Faster Than We Could

Design systems aren’t just component libraries. They are services. Given this, their value depends on how easily people can access, understand, and implement what you’re offering. As adoption of our design system grew, our support load grew faster than our team could keep up with, and our consumer sentiment survey showed it. Satisfaction with the system’s ease of use and its support resources had dropped 6% and 7%, respectively.

Over one quarter, I led an overhaul of our design system documentation that cut our support load by 90%, from roughly 128 hours per quarter to 13. That same documentation went on to power our design system’s MCP server, which made design system related tasks eight times faster.

Fragmented, Inconsistent, and Not Ready for Agents

Our documentation lived in three places. Figma for design specs, Storybook for developers, and SharePoint for everything else. Guidance drifted out of sync, coverage was uneven, and the people it was meant to serve largely ignored it.

AI tools were also starting to show up in our consumers’ workflows. Fragmented, inconsistent content is hard enough for a person to navigate. For an agent, it’s a recipe for confidently wrong answers.

Three Decisions That Mattered

After auditing and scoring every artifact to turn the cleanup into a ranked backlog, three decisions shaped the rest of the work.

1. Migrate first, perfect later

I pitched leadership on consolidating everything into a single documentation platform, framed around what it would unlock: adoption, less support overhead, and closer collaboration between design and development. It landed, and we got the budget.

That left a choice. Perfect the content before migrating, or migrate it as-is and improve it in place. I chose to migrate first. One URL was an immediate win on its own, it showed stakeholders the value of their investment quickly, and it meant we’d never maintain the old resources while standing up the new ones.

2. One schema for humans and agents

The audit’s biggest finding was that no two pages were documented the same way. I created a content framework for each type of documentation (components, patterns, foundations) and wrote it as a schema with explicit standards for what every section had to contain.

For people, that meant a predictable structure. You always knew where to find an overview, an anatomy diagram, usage guidance, or the anti-patterns to avoid. For agents, it meant content they could reliably parse and reason over. Designing for both from the start is what made everything that followed possible.

3. Scale through standards, not effort

With the schema in place, I paired it with agent instructions that took an existing page, plus my notes from the audit, and drafted a rewrite against the schema. Before drafting, the agent asked for the context only a person could supply. Who uses the component, how it gets misused, and how it relates to its neighbors. It didn’t produce publish-ready docs, but it turned days of work per page into hours, and it let me focus on reviewing, correcting, and extending.

That workflow is what let me scale beyond myself. I rewrote the majority of the documentation and delegated the rest to teammates, who used the same schemas, agent instructions, and visual standards to deliver work that matched. That had a benefit beyond speed. Asking the whole team to write against shared standards forced us to codify the system’s point of view together.

As More People Used the Docs, Fewer Needed Us

View data

Indexed (FY25 Q3 = 100)	FY25 Q3	FY25 Q4	FY26 Q1	FY26 Q2
Doc views	100	172	190	222
Support submissions	100	84	55	42
Support hours	100	74	46	10

Support hours fell 90%, from roughly 128 per quarter to 13, estimated from the story points we spent on support. Support submissions fell 58% over the same four quarters, while site views grew 122%. The relationship held quarter over quarter, as more people used the docs, fewer people needed us.

From the Docs Site to the IDE

The bigger payoff came next. An engineering partner built our design system’s MCP server, and my documentation became its ask_atmosphere capability. Instead of leaving their editor to search a docs site, engineers and designers ask their agent how to install the system, which token to use, or how a component should behave, and the agent answers from the same source of truth people read. Because I’d written most of that source, I was also one of the primary internal design testers, checking the agent’s answers against the docs.

Since launching in November 2025, ask_atmosphere has handled more than 574,000 requests, and an internal benchmark by our engineering lead found design system related tasks were eight times faster with it.

The Foundation Was the Point

I started this work to reduce our support burden, and it did. But the bigger lesson is that documentation is infrastructure. The same structured, standards-driven content that helps a person self-serve is exactly what an agent needs to give a correct answer. If I were standing up a design system today, I’d write the schema before the first component.