Overview
Documentation was the opportunity. Delivery was the problem.
A large enterprise healthcare client wanted to know where AI could meaningfully improve design and development workflows. I was brought in as a documentation specialist on a consulting engagement led by Big Medium to explore that question across seven opportunity areas. Documentation was one of them, specifically, whether AI could support the creation and maintenance of design system usage guidelines at scale.
That's where this work began. The question wasn't whether AI could help. It was what help actually needed to look like.
In partnership with Big Medium
2024
Process
The problem with AI-assisted documentation isn't the AI.
Most teams hit the same wall. They point a model at their design system and expect useful guidance to come back. What comes back is generic, inconsistent, and disconnected from the system's actual intent.
The model isn't the problem. The documentation it's working from is.
Design system documentation is rarely structured for retrieval. It's written for browsing — paragraphs of guidance that assume a human reader who will fill in gaps and apply judgment. That works for people. It doesn't work for AI. A model given unstructured content will produce unstructured output.
The first proof of concept made this visible. Since the client's documentation wasn't available for the test, the Salesforce Lightning Design System served as a stand-in and as a well-documented public system that could prove the concept without requiring proprietary assets. The setup was straightforward: structure the documentation as a knowledge base, give a model access to it, and ask it to provide context-specific guidance for design components.
Where guidance was vague, the output was vague. Where intent wasn't stated explicitly, the model filled the gap with assumptions. Human readers compensate for documentation gaps without noticing. AI doesn't. It works from what's there, and when what's there is incomplete, the output makes that visible in a way no documentation audit ever quite does.
The real question wasn't whether AI could write docs. It was about getting the right docs to the right person at the right time.
The prompt framing evolved through several iterations before landing there. Early versions asked what AI could do with documentation. Later versions asked something more specific: what a designer actually needs, when they need it, and where they are when they need it.
The engagement brief evolved through three prompts before landing on the question that shaped the work.
The answer was already obvious once the question was right. Designers were in Figma. The documentation wasn't.
Two custom GPTs were developed as part of the POC — one to demonstrate that structured documentation could power context-specific guidance, one to help contributors create that documentation more consistently in the first place. Both were proof that the concept worked. The destination was the plugin.
Outcome
Documentation doesn't fail at the content layer. It fails at the delivery layer.
The pilot deliverable was a Figma plugin that surfaced just-in-time usage guidelines for design system components — pulling from structured documentation and delivering it inside the tool where designers were already working.
Most design systems have documentation. The guidance exists. What breaks down is the gap between where documentation lives and where design decisions actually happen.
The plugin closed that gap. Structured documentation surfaced in context, as needed. The content didn't change. The delivery did.