How to Set Up AI-Powered Design System Documentation (Step by Step)
I design and scale structured Design Systems across complex products.
Currently exploring how AI fits into system architecture — not as a replacement for thinking, but as a multiplier for structured workflows.
Interested in governance, token architecture, documentation systems and operational design.
Writing about experiments, lessons learned and practical implementation.
Last week I shared how I automate Design System documentation with Claude AI.
Many of you asked: "How do I actually set this up?"
Here's the step-by-step. No fluff. Just what works.
Step 1: Prep your Figma
Before you touch any AI tool — clean your house first.
Your Figma file IS the input. If it's messy, your docs will be messy.
Minimum hygiene checklist:
- Layer names make sense (no "Frame 237")
- Components use Auto Layout
- Tokens/variables are organized in collections (not scattered hex values)
- Variants are properly defined with named properties
This isn't optional. Skip this and nothing else works.
Step 2: Choose your connection method
You have two options. Pick one:
⚡ Option A: Figma MCP + Claude Desktop (recommended)
Claude reads your Figma files directly. No manual export.
- Install Claude Desktop app
- Enable Figma MCP in settings
- Authenticate with your Figma account
- Claude can now access your components, variables, and structure
This is the power setup. Claude sees everything — variants, tokens, auto-layout, constraints.
🔧 Option B: Manual (works with any AI)
- Open your component in Dev Mode
- Copy the relevant specs (properties, tokens, spacing)
- Paste into Claude (web or desktop) with your request
Less powerful, but zero setup. Good for trying things out.
Step 3: Teach Claude your system
This is where most people fail. They jump straight to "write docs for my Button" without context.
Claude doesn't know your token architecture, naming conventions, or governance model.
You need a system prompt. Think of it as onboarding a new team member.
Tell Claude:
- Your token layers (e.g., base → semantic → component)
- Your naming convention (kebab-case? camelCase?)
- Your source of truth (Figma for design tokens? Code for component tokens?)
- Your platforms (Web only? Web + mobile?)
- Your quality bar (WCAG AA? AAA?)
I shared my full system prompt template in last week's comments. Still there — grab it.
Step 4: Start small
Don't try to document 50 components on day one.
Pick ONE component you know well. Generate the spec with AI. Compare it to what you'd write manually.
You'll immediately see:
- What Claude gets right (structure, completeness)
- What it misses (your team's conventions, edge cases)
- What you need to add to your system prompt
Iterate your prompt based on this. 3-4 rounds and you'll have a prompt that consistently delivers 80-90% done specs.
Step 5: Scale it
Once your prompts are dialed in, go wide:
- Batch audit: feed 10-20 components → get a consistency report in minutes
- ADRs: describe the decision context → get a production-ready record
- Handoff docs: point at a component → get props API, tokens, states, accessibility — all at once
The key insight: your prompt library IS your documentation standard. Treat it like code. Version it. Improve it.
TL;DR
- Clean your Figma first — garbage in, garbage out
- Connect Claude to Figma (MCP or manual)
- Write a system prompt that teaches Claude YOUR system
- Test on one component, iterate the prompt
- Scale to batch audits, ADRs, and handoff docs
The setup takes an afternoon. The time saved compounds every single week.
What's your biggest blocker to trying this? Let me know in the comments — happy to help.
