A design system rarely dies from bad ideas. It dies from slow mechanics: naming layers, duplicating variants, hand-writing token JSON, then explaining to a developer for the fifth time why color/text/secondary is not the same as color/neutral/700. Figma's own documentation on variables and component properties shows how much of that work is structurally repeatable — which is exactly the kind of work an LLM handles well.
The trick is not asking AI to "design a system." It is feeding it the right constraints (naming conventions, token tiers, component API, platform targets) and asking for artifacts you can paste directly into Figma: variable collections, component sets, description fields, and documentation. Below are 10 prompts I use for that, each with a real example. They assume you already know your way around Figma variables, auto layout, and component properties — and if you don't, the prompts are written so the output teaches you the pattern as you go.
Grounding note: token structure follows the W3C Design Tokens Community Group format (
$value/$type) and the three-tier model (primitive → semantic → component) described in the DTCG spec and in Material Design 3's token documentation. Nothing here invents new Figma features — only uses variables, styles, component properties, and descriptions as they exist.
1. Token architecture generator (primitive → semantic → component)
What it's for: turning a brand palette into a layered token system before you touch a single frame.
You are a design systems architect. Build a 3-tier token architecture.
Inputs: brand colors: #0F172A, #2563EB, #F59E0B, #FFFFFF, #F1F5F9.
Output:
1. Primitive tier: neutral/blue/amber scales 50-900 with hex values.
2. Semantic tier: bg/*, text/*, border/*, action/* mapped to primitives.
3. Component tier: button/*, input/*, card/* mapped to semantic.
Return a Markdown table: token name
| tier | value | alias target.
Then output the same set as W3C DTCG JSON with $value and $type.
Example output fragment:
{
"color": {
"text": {
"primary": { "$value": "{color.neutral.900}", "$type": "color" },
"secondary": { "$value": "{color.neutral.600}", "$type": "color" }
},
"action": {
"primary": { "$value": "{color.blue.600}", "$type": "color" }
}
}
}
Paste the JSON into a Tokens Studio-style import or map it manually into a Figma variable collection named color. Three tiers keep dark mode sane: you swap semantic aliases, primitives stay untouched.
2. Figma variable collection blueprint
What it's for: deciding collection structure, modes, and scopes before creating 400 variables by hand.
Design a Figma variable plan for a SaaS product with light/dark themes and 3 breakpoints.
For each collection give: name, variable types (COLOR, FLOAT, STRING, BOOLEAN),
modes, and which scopes to enable (e.g. TEXT_FILL, FRAME_FILL, CORNER_RADIUS).
Flag variables that must NOT be exposed to designers to prevent misuse.
Why it matters: in Figma, modes live on collections, not individual variables. So spacing and radius belong in one collection with a single mode, while color needs Light/Dark. Getting this wrong early means re-binding hundreds of layers later. Ask the model to justify each collection boundary — the reasoning is often more useful than the table.
3. Component API definition prompt
What it's for: designing a button, input, or card as a contract, not a picture.
Define the component API for a Button in Figma.
Output a table: property name | type (variant/boolean/text/instance swap) |
default
| allowed values | notes.
Constraints: 5 variants max, no nested variants for state,
use boolean for icon-left/icon-right, text property for label.
Then list the exact variant set names (e.g. Type=Primary, Size=MD).
Example result:
| Property | Type | Default | Values |
|---|---|---|---|
| Type | Variant | Primary | Primary, Secondary, Ghost |
| Size | Variant | MD | SM, MD, LG |
| State | Variant | Default | Default, Hover, Disabled |
| Icon left | Boolean | false | — |
| Label | Text | "Button" | — |
The rule of thumb: variants multiply (3×3×3 = 27 frames), booleans don't. Push optionality into booleans and instance swaps.
4. Variant matrix compressor
What it's for: when a component set has exploded and you need to cut it down without losing coverage.
Here is my current variant list for Input: [paste names].
Find combinations that are visually identical or nonsensical
(e.g. State=Disabled + Type=Focused).
Propose a reduced matrix, explain each removal, and give the
boolean/instance-swap replacements.
This is the single highest-ROI prompt in the list. Designers routinely ship component sets where 40% of variants are duplicates. The model is good at spotting Size=SM + Type=Compact redundancy because it's a naming problem, not a pixel problem.
5. Auto layout spec generator
What it's for: consistent spacing inside components without eyeballing.
For each component below, define auto layout: direction, gap, padding,
resizing (Hug/Fill/Fixed), and min/max width.
Use only spacing tokens: 4, 8, 12, 16, 24, 32.
Components: Button, Input, Card, Modal, Toast, Table row.
Output as a table plus a note on which frames should be Fill vs Hug.
Bind the gap and padding values to your spacing/* variables so a single token change ripples through the kit. That is the difference between a component library and a design system.
6. Naming convention enforcer
What it's for: stopping Button/Primary/Large/Copy 2 from entering the file.
Adopt this convention: Component=Value, layers in PascalCase,
no spaces, no slashes inside property values.
Given this list of layer names [paste], rewrite them to comply
and return a before/after table with the rule violated.
Figma component properties are already slash-free and case-sensitive; matching that in layer names keeps the Dev Mode handoff readable and makes plugin-based audits possible later.
7. Component description writer
What it's for: filling the description field that 90% of teams leave empty.
Write Figma component descriptions for: Button, Input, Card.
Each description: purpose (1 sentence), when to use, when NOT to use,
related components, and the token names it consumes.
Max 60 words. Plain language, no marketing tone.
Descriptions show up in Dev Mode and in the assets panel — this is where the system documents itself without a separate wiki. Keep them short or nobody reads them.
8. Accessibility audit prompt
What it's for: catching contrast and target-size issues before QA does.
Audit these token pairs for WCAG 2.2 contrast:
[paste text/bg pairs with hex values].
For each: compute contrast ratio, state pass/fail for AA normal text (4.5:1),
AA large text (3:1), and AAA (7:1). Suggest the nearest passing primitive.
WCAG 2.2 (W3C Recommendation, October 2023) keeps 4.5:1 for normal text under SC 1.4.3; target size minimum is 24×24 CSS px under SC 2.5.8. LLMs are reliable at the arithmetic here if you give exact hex values — and unreliable if you ask them to "estimate" from screenshots. Always pass numbers, not images.
9. Documentation page generator
What it's for: producing the "how to use this component" page in one pass.
Generate a docs page for the Card component in Markdown.
Sections: Overview, Anatomy (list slots), Variants, Do/Don't (3 each),
Accessibility notes, Tokens used, Code mapping (CSS variables).
Keep it under 400 words. No lorem ipsum, no placeholders.
The "code mapping" section is what makes the system usable by engineers: --color-bg-surface next to bg/surface next to the Figma variable name. One source of truth, three vocabularies.
10. Sprint plan prompt (the one that actually ships it)
What it's for: sequencing the work so a design system lands in five days, not five months.
Plan a 5-day design system sprint for one designer + one engineer.
Deliverables per day, dependencies, and a definition of done per artifact.
Constraints: tokens first, then 6 core components (Button, Input, Select,
Card, Modal, Toast), docs last. Include a review checkpoint on day 3.
Realistic shape: Day 1 — audit + token architecture; Day 2 — Figma variable collections and modes; Day 3 — component APIs and builds; Day 4 — descriptions, docs, accessibility pass; Day 5 — handoff, Dev Mode check, and a lint pass on naming. It's tight, but the bottleneck in most teams is decisions, not pixels — and that's precisely what prompts compress.
What this actually buys you
None of these prompts design anything for you. They force the decisions — token tiers, component APIs, variant limits, naming rules — into a written form you can review, argue with, and version. That's the real output of a design system sprint: a set of decisions with evidence, not a Figma file.
Start with prompt #1 and #10 today. The first gives you the skeleton, the second gives you the deadline. Everything else fills in between — and by Friday you'll have variables bound, components described, and a docs page a developer can actually read. If you want to go deeper into prompt patterns for design and engineering work, the ASI Biont blog has more breakdowns worth bookmarking.
Comments