Design systems are rarely built by a dedicated team of designers anymore. In many product teams, one person juggles Figma, tokens, component libraries, and handoff to developers — often without a formal design system background. LLMs can fill that gap, but only if you ask them the right way. Below are 12 prompts that turn a text model into a UI/UX assistant: they generate and validate design tokens, audit components, write interface copy, check contrast, and prepare specifications for developers.
1. Design token generator from a brand description
Task: Get a structured set of design tokens (colors, spacing, typography) from a short brand brief.
Prompt:
You are a design system architect. Based on this brand description:
[brand: fintech app, trustworthy, calm, dark mode first]
Generate a design token set in JSON with categories: color (primary, secondary, neutral, semantic), spacing (4px base), typography (sizes, weights, line-heights).
Use a consistent naming convention: category.concept.variant.
Output only valid JSON, no explanations.
Example result:
{
"color.primary.500": "#1A4D8F",
"color.neutral.100": "#F5F7FA",
"spacing.4": "16px",
"typography.body.size": "14px"
}
This prompt works because it forces a naming convention upfront. Without it, LLMs produce inconsistent keys like mainBlue and primary-color. The trade-off: you get a plausible starting point, not a tested system. Always run the output through a contrast checker before committing.
2. Palette expansion with accessibility constraints
Task: Extend a base palette to full 50–900 scales without breaking contrast.
Prompt:
Given base color #1A4D8F, generate a 10-step tint/shade scale (50 to 900).
For each step, state the hex code and the contrast ratio against white (#FFFFFF) and black (#000000).
Flag any step where contrast against white is below 4.5:1.
Example result: the model returns a table where 500 has 7.2:1 against white and 200 has 2.1:1 — flagged. You immediately see which steps are safe for text and which are only for backgrounds.
3. Component audit against your own checklist
Task: Review a component description and find inconsistencies.
Prompt:
Act as a design system auditor. Here is a component spec:
Button: variants primary/secondary/ghost, sizes sm/md/lg, states default/hover/active/disabled.
Check for: missing states, inconsistent naming, missing focus state, unclear disabled behavior.
List issues as a numbered list with severity (high/medium/low).
Example result: "High: no focus-visible state described. Medium: ghost variant lacks disabled styling. Low: size naming sm/md/lg inconsistent with spacing tokens 4/8/12."
This is the fastest way to catch gaps before a component reaches the library. The model doesn't see your Figma file — it only sees what you describe, so the quality of the audit depends on how completely you write the spec.
4. Auto-layout debugging assistant
Task: Diagnose why a layout breaks when resizing.
Prompt:
A Figma frame uses auto-layout vertical, gap 8, padding 16, hug contents.
Inside: a text block and an icon. When the text is long, the icon shrinks.
Explain why and give the fix in terms of auto-layout settings (fill container, fixed width, min-width).
Example result: the model explains that the icon has fill container enabled, so it absorbs remaining space. Fix: set icon to fixed width and text to fill container. This prompt saves time because auto-layout bugs are usually one setting away — the hard part is knowing which one.
5. Microcopy for every component state
Task: Generate UI text for empty, error, and success states.
Prompt:
Write microcopy for a file upload component. States: empty, uploading, success, error (file too large), error (wrong format).
Tone: friendly, concise, no exclamation marks. Max 8 words per message. Include a button label for each state.
Example result: empty — "Drag files here or browse"; error (too large) — "File exceeds 10 MB. Try a smaller one." Button: "Choose another."
Microcopy is where design systems quietly fail: the component is perfect, but the text is written ad hoc by whoever implements the screen. A prompt like this creates a single source of truth for state messaging.
6. Contrast and accessibility pre-check
Task: Catch WCAG issues before a designer opens a checker.
Prompt:
Check this color pair for WCAG 2.1 compliance: text #777777 on background #FFFFFF, font size 14px, regular weight.
State the required ratio for normal text (4.5:1), the actual ratio, and pass/fail.
Suggest the nearest darker gray that passes while staying neutral.
Example result: ratio ≈ 4.48:1 — fail by a hair. Suggested replacement: #767676 passes at 4.54:1. That one-step difference is exactly the kind of thing designers miss visually but auditors catch instantly.
7. Design spec generator for handoff
Task: Turn a component into a developer-ready spec.
Prompt:
Write a handoff spec for a Card component. Include: anatomy, dimensions, spacing tokens, typography tokens, states, responsive behavior (breakpoints 320/768/1200), and edge cases (long title, missing image).
Format as Markdown with a table for tokens.
Example result: a Markdown doc with a token table (spacing.4 = 16px, typography.body.size = 14px) and a list of edge cases. Developers get a checklist instead of a screenshot with redlines.
8. Naming convention enforcer
Task: Normalize inconsistent component and token names.
Prompt:
Here is a list of component names: BtnPrimary, card-small, NavBar, modal_Dialog, inputField.
Apply a single convention: PascalCase, no abbreviations, noun-first.
Return a mapping table old → new, and flag names that are ambiguous.
Example result: BtnPrimary → ButtonPrimary, card-small → CardCompact, modal_Dialog → DialogModal (flagged: redundant). Consistent naming is boring until you search a library of 200 components and can't find anything.
9. Responsive breakpoint planner
Task: Decide how a layout should adapt across screens.
Prompt:
Design a responsive plan for a dashboard with sidebar, header, and content grid.
Breakpoints: mobile <768, tablet 768–1199, desktop ≥1200.
For each breakpoint describe: sidebar behavior, grid columns, header height, and what collapses first.
Example result: mobile — sidebar becomes a drawer, grid 1 column; tablet — sidebar collapsed to icons, grid 2 columns; desktop — full sidebar, grid 3 columns. This gives developers a decision tree instead of "make it responsive."
10. Component documentation writer
Task: Generate usage docs for a component library.
Prompt:
Write documentation for a Tooltip component. Sections: when to use, when not to use, props (content, placement, delay), accessibility notes (keyboard, screen reader), and 3 usage examples in plain language.
Keep it under 250 words.
Example result: a short doc that says "use for supplementary info, not for critical actions" and lists keyboard behavior. Documentation is the part of a design system that always gets postponed — a prompt makes it a 5-minute task.
11. Design review checklist from a PRD
Task: Turn product requirements into a design QA checklist.
Prompt:
From this product requirement: [user can filter a list by date, status, and search], create a design review checklist.
Include: states (loading, empty, error), edge cases (no results, very long query), accessibility (keyboard navigation, labels), and responsive considerations.
Example result: a checklist with items like "empty state has a clear action" and "search input has a visible label, not just a placeholder." This catches requirements that were never designed for — the most expensive kind of miss.
12. Handoff Q&A simulator
Task: Anticipate developer questions before the handoff meeting.
Prompt:
You are a developer receiving this design spec: [paste spec].
List the 10 questions you would ask the designer before starting implementation.
Order them by risk: what would block work first.
Example result: "1. What happens to the card height when the title wraps to 3 lines? 2. Is the hover state animated, and what's the duration? 3. Which tokens map to the disabled state?"
This prompt flips the direction: instead of the designer explaining, the model simulates the developer's confusion. Most handoff friction comes from unasked questions, not from missing redlines.
What these prompts actually change
None of these prompts replace a design system. They compress the boring, error-prone parts: naming, documentation, state coverage, and handoff specs. The designer still makes the visual decisions; the model handles the structured text around them.
The main limitation is context. An LLM doesn't know your library, your tokens, or your team's conventions unless you tell it. The prompts above work best when you keep a reusable "system context" block — token names, component list, tone of voice — and paste it at the start of each request.
If you want to go deeper into Figma workflows, component thinking, and the design process from wireframe to handoff, see our UI/UX design with Figma guide. For teams working at the intersection of design and code, the web dev lead prompts cover the engineering side of the same handoff.
Start with one prompt — the token generator or the handoff spec — and see how much time it saves. The rest will follow naturally.