Every design team eventually hits the same wall: someone decides they need a “proper design system,” and three weeks later everyone’s arguing about whether the primary button should be 4px or 6px rounded. The actual token architecture, component logic, and documentation? Still blank. Gemini 2.5 Pro won’t fix the internal politics, but it can do an embarrassing amount of the structural work that usually takes a senior designer a full week to produce.
To be straight with you before we dive in: there is no official “Component Generator” feature in Gemini 2.5 Pro. That’s fiction. What does exist — and what this tutorial covers — is a practical workflow using Gemini’s actual capabilities: a 1 million token context window, strong code generation across multiple languages, and genuinely useful reasoning about design systems. You’ll use Gemini through AI Studio, the Gemini API, or the chat interface at gemini.google.com to generate design tokens, component specs, CSS/JSON exports, and documentation that you then bring into Figma manually or via plugins. It’s a workflow, not a button. But it works.
This is a step-by-step guide for design teams who want to use Gemini 2.5 Pro to generate a coherent, scalable design system from scratch — tokens, components, states, accessibility notes, and Figma-ready JSON — without paying an agency or waiting six months for your company to buy a Figma Enterprise seat that unlocks a feature you’ll never use.
By the end of this workflow, you’ll have a full design token set in JSON format (compatible with Figma Tokens or the Variables API), structured component specifications for at least your core UI components, responsive state documentation, and a repeatable prompt library you can hand to any team member. The outputs live in files you own. Gemini is the generator; you’re the architect.
You need access to Gemini 2.5 Pro — either through Google AI Studio (aistudio.google.com, free tier available) or the Gemini Advanced subscription. AI Studio is the better choice here because you can set a system prompt that persists across the session, which matters a lot for consistency. You’ll also want a Figma account with the Figma Tokens plugin (by Jan Six) or the newer Variables import workflow. Finally, have a rough brand brief handy — at minimum your brand colors, one or two typeface names, and a general aesthetic direction (“clean and minimal” or “bold and editorial” is enough to start).
Pro tip ✅
Use Google AI Studio over the standard Gemini chat for this workflow. The system prompt field lets you lock in your design system’s constraints once, and every subsequent generation respects them automatically. This alone saves you from re-explaining your brand on every prompt.
Open AI Studio, create a new chat, and paste this into the System Instructions field before you do anything else. This is your design brief that Gemini will reference for the entire session.
You are a senior product designer and design systems engineer. Your job is to help me build a complete, production-ready design system.
Brand name: [YOUR BRAND]
Primary brand color: [HEX CODE]
Secondary brand color: [HEX CODE]
Neutral palette: generate a 10-step grayscale from white to near-black
Typography: [FONT NAME] for headings, [FONT NAME] for body text
Design aesthetic: [e.g. "clean, minimal SaaS product — think Linear or Notion"]
Platform target: Web (React) and mobile (iOS/Android considerations noted)
Accessibility requirement: WCAG 2.1 AA minimum
When generating tokens, always output valid JSON in W3C Design Token format.
When generating components, output both a written spec and a CSS custom properties implementation.
Always include light mode and dark mode variants.
Always include at least 4 interactive states: default, hover, active/pressed, disabled.Fill in your actual brand values before pasting. The instruction to output W3C Design Token format is critical — it’s what makes your JSON importable into Figma Variables via the Tokens Studio plugin.
With the system prompt set, start with your foundation tokens. This is the layer everything else inherits from.
Generate a complete set of foundation design tokens for this brand system. Include:
- Color tokens: primary (10 shades 50–900), secondary (10 shades), neutral/gray (10 shades), semantic colors (success, warning, error, info — each with background, border, text, and icon variants)
- Spacing tokens: a base-8 scale from 2px to 96px, with named aliases (spacing-xs, spacing-sm, spacing-md, spacing-lg, spacing-xl, spacing-2xl, spacing-3xl)
- Border radius tokens: none, sm (4px), md (8px), lg (16px), full (9999px)
- Shadow tokens: 4 elevation levels for light mode and 4 for dark mode
- Typography tokens: font families, a modular type scale (12/14/16/20/24/32/40/48px), line heights, font weights, letter spacing values
Output as W3C Design Token format JSON, grouped by category.Gemini 2.5 Pro will return a JSON block that’s several hundred lines long. Copy it into a file called foundation.tokens.json. This is your single source of truth.
Note 💡
The W3C Design Token Community Group format uses a specific structure:
{ "color": { "primary": { "500": { "$value": "#your-hex", "$type": "color" } } } }. Gemini 2.5 Pro handles this correctly if you ask for it explicitly. If the output doesn’t include$typeannotations, just ask: “Add $type annotations to all tokens.”
Foundation tokens are the raw material. Semantic tokens are how your components actually refer to colors — they’re the difference between a component hardcoding blue-600 and correctly referencing interactive-primary. This layer is what makes dark mode not a nightmare.
Now generate semantic token aliases that reference the foundation tokens. Create semantic tokens for:
- Background: bg-default, bg-subtle, bg-surface, bg-overlay, bg-inverse
- Text: text-default, text-subtle, text-placeholder, text-disabled, text-inverse, text-link, text-link-hover, text-on-primary
- Border: border-default, border-subtle, border-strong, border-interactive, border-error
- Interactive: interactive-primary, interactive-primary-hover, interactive-primary-pressed, interactive-primary-disabled
- Interactive secondary and tertiary variants following the same pattern
- Focus: focus-ring color and width
Map each semantic token to the appropriate foundation token value for both light mode and dark mode. Output as a second JSON file called semantic.tokens.json using W3C format with $value referencing the foundation token paths using curly-brace notation, e.g. {color.primary.600}.The curly-brace reference notation is native to Tokens Studio’s plugin and to the W3C draft spec. When you import both files into Figma Tokens, it resolves the references automatically into actual Figma Variable values.
Pro tip ✅
Don’t skip the semantic layer and just use raw foundation tokens in components. It feels faster for five minutes and then you spend three hours manually updating 200 component instances when someone decides the brand blue should be slightly darker. Semantic tokens exist so that “slightly darker blue” is one change, not two hundred.
Now the good part. Start with your highest-frequency component: the Button. Every other component specification will be faster once you establish this pattern.
Generate a complete component specification for a Button component. Include:
- All variants: Primary, Secondary, Tertiary, Destructive, Ghost, Link
- All sizes: Small (32px height), Medium (40px height), Large (48px height)
- All states: Default, Hover, Active/Pressed, Focus (with focus ring), Loading (with spinner), Disabled
- Icon support: icon-only, leading icon + label, trailing icon + label
- Anatomy: list every sub-element (container, label, leading-icon, trailing-icon, spinner, focus-ring) with their token references
- Spacing: internal padding using spacing tokens for each size variant
- Typography: font size, weight, line-height token references per size
- Behavior notes: keyboard interaction (Enter/Space to activate), ARIA attributes (role, aria-disabled vs disabled attribute, aria-busy for loading state)
Output the spec as:
1. A written component spec in markdown
2. A CSS implementation using custom properties that reference the semantic tokens
3. A JSON structure describing the component variants for Figma Variables mappingRun this same prompt for every component you need, swapping “Button” for your target. For a minimum viable design system, generate specs for: Button, Input/TextField, Select, Checkbox, Radio, Toggle/Switch, Badge/Tag, Card, Modal/Dialog, Toast/Alert, Navigation items, and Avatar. That covers roughly 80% of what most product teams build.
Generate a complete component specification for a TextField / Input component following the same format as the Button spec above. Include:
- Variants: Default, With label, With helper text, With error message, With character count, With leading icon, With trailing icon/action
- States: Empty, Focused, Filled, Error, Disabled, Read-only
- Sizes: Small, Medium, Large
- Anatomy: wrapper, label, input-container, leading-slot, input-element, trailing-slot, helper-text, error-message, character-count
- All spacing and typography using semantic token references
- Accessibility: aria-required, aria-invalid, aria-describedby patterns
- CSS custom properties implementation
- JSON variant mapping for FigmaWarning ⚠️
AI-generated component specs will occasionally get ARIA attributes wrong or suggest patterns that are technically accessible but practically annoying to screen reader users. Always run your specs past WebAIM’s checklist or, if you have the budget, an actual accessibility audit. Gemini gets the basics right most of the time. “Most of the time” is not good enough for production.
Here’s where the 1 million token context window earns its keep. You can paste your entire token JSON plus all your component specs into a single session and ask Gemini to generate cross-referenced documentation. This is the part that usually gets skipped and then everyone suffers six months later when a new designer joins and asks why the card component uses a different shadow than the modal.
I'm going to paste my complete design token JSON and component specs. After I do, generate:
1. A "Design System Usage Guide" markdown document covering: when to use each token category, common mistakes to avoid, how to handle spacing in layouts
2. A component decision guide: for each component, one paragraph on when to use it vs. its alternatives
3. A "Dark mode implementation guide" explaining how the semantic token layer handles theming
4. An "Accessibility quick reference" table listing each component with its ARIA role, required attributes, and keyboard interactions
[PASTE YOUR foundation.tokens.json AND semantic.tokens.json AND component specs here]The output won’t be Pulitzer-level prose, but it’ll be accurate, structured, and something a developer or designer can actually reference. Edit it for your team’s voice, but the structure does the hard work.
This step requires the Tokens Studio plugin (formerly Figma Tokens) by Jan Six. Install it from the Figma Community. Once installed, open the plugin in your Figma file.
In Tokens Studio, click the sync settings and choose “Local” storage. Then import your foundation.tokens.json first, followed by semantic.tokens.json. The plugin resolves the {color.primary.600} references automatically. Hit “Apply to document” and Tokens Studio creates Figma Variables from your JSON — your entire token set becomes native Figma Variables you can assign to frames, text layers, and auto-layout components directly.
Pro tip ✅
When building your Figma components from the specs Gemini generated, use the component anatomy JSON to structure your Figma component layers in the same order with the same names. When your Figma layer names match your token structure (e.g., a layer named “label” getting the “text-default” variable), handing off to developers becomes a conversation about specs instead of a scavenger hunt.
The final step turns this from a one-time project into a repeatable workflow. Create a shared document with your system prompt template and a library of component prompts. When your team needs a new component — say, a Data Table or a Date Picker — they load the system prompt, paste the token context, and run a standardized prompt.
Using the design token system and component patterns already established in this session, generate a complete component specification for a [COMPONENT NAME] component.
Follow the same format as the Button spec: written spec in markdown, CSS custom properties implementation, JSON variant mapping.
Additional requirements specific to this component:
- [ADD ANY SPECIFIC REQUIREMENTS HERE]
Cross-reference existing components where appropriate (e.g., if this component uses a Button internally, reference the Button spec).That template, saved in Notion or Confluence with your actual token files attached, means any designer or developer can generate a new component spec in about five minutes. The work you did in Steps 1–5 pays dividends every time someone adds to the system.
Avoid 🚫
Don’t generate every component spec in one massive prompt. Gemini handles it technically, but the outputs get less specific and more template-y as the list grows. One component per prompt, then ask Gemini to “cross-reference” with previous specs. You get better output and it’s easier to catch errors before they compound.
The honest summary: Gemini 2.5 Pro is genuinely useful for design systems work, not because it has special design features, but because it understands design token architecture, writes clean CSS, and can hold your entire system in context while generating new pieces of it. The 1 million token window means you’re not constantly re-explaining your foundation — paste it once and iterate for hours.
Where this workflow still requires you: Figma component building (Gemini generates specs, not Figma files), accessibility testing beyond automated checks, and any visual decision that requires actual taste. AI is better at structural thinking than aesthetic judgment, and design systems are mostly structural thinking with a thin layer of aesthetic judgment on top. Use it for the former, trust humans for the latter.
As Figma’s Variables API matures and plugins like Tokens Studio get tighter, the gap between “Gemini generated this JSON” and “this is live in your Figma library” is going to keep shrinking. Right now the import step is a few minutes of manual work. That’s a reasonable trade for having your entire token system generated, documented, and cross-referenced in a single afternoon.
