A text LLM can't see your Figma canvas, yet it can still save you hours on the boring parts of UI design: generating design tokens, auditing a layout against Nielsen's heuristics, checking contrast ratios, and writing a handoff spec that developers don't have to decode. The trick is knowing which prompts produce usable output and where the model will confidently hallucinate pixel values or confuse a percentage with a point.
This roundup is a working cheat sheet. Each prompt is copy‑paste ready, comes with a real usage example, and shows what you get back — plus a note on where to double‑check by hand in Figma. No magic, just a design partner that never sleeps but sometimes miscounts.
1. Design tokens from a brand description
For: turning a loose brand brief into a structured set of tokens you can paste into Figma Variables (or a JSON file for Style Dictionary).
Prompt:
You are a design systems engineer. Based on the brand description below, generate a token set with:
- 8 color roles (primary, primary-hover, surface, surface-alt, text-primary, text-secondary, border, error) with hex values
- a modular type scale (base 16px, ratio 1.25) with line‑height and font‑weight per step
- a spacing scale on a 4px grid (8 steps)
- border‑radius and elevation tokens
Output as a JSON object with keys: color, typography, spacing, radius, elevation. Add a one‑line rationale for each color choice.
Brand: [your description]
Example input:
Brand: B2B analytics SaaS, trustworthy but not corporate, primary audience is data teams. Prefer cool blues and a warm accent for alerts.
Output (excerpt):
{
"color": {
"primary": "#1A5CFF",
"primary-hover": "#0F4AD6",
"surface": "#FFFFFF",
"surface-alt": "#F5F7FA",
"text-primary": "#0B1B3A",
"text-secondary": "#5A6B85",
"border": "#D9E1EC",
"error": "#D92D20"
},
"typography": {
"base": { "size": "16px", "lineHeight": "24px", "weight": 400 },
"h3": { "size": "20px", "lineHeight": "28px", "weight": 600 },
"h2": { "size": "25px", "lineHeight": "32px", "weight": 600 },
"h1": { "size": "31px", "lineHeight": "40px", "weight": 700 }
},
"spacing": [0, 4, 8, 12, 16, 24, 32, 48],
"radius": { "sm": "4px", "md": "8px", "lg": "12px" },
"elevation": { "card": "0 1px 2px rgba(16,24,40,0.06)" }
}
Where to verify: contrast ratios and actual hex values. The model often picks a primary that fails WCAG AA on white — always run the pair through a contrast checker before importing into Figma Variables.
2. Nielsen heuristic audit from a screen description
For: a structured UX review when you have a screenshot but no time for a full heuristic evaluation.
Prompt:
Act as a UX auditor. I will describe a screen. Evaluate it against Jakob Nielsen's 10 usability heuristics. For each heuristic, give: verdict (pass / risk / fail), the exact element that triggers the verdict, and a concrete fix. Do not invent elements I did not mention. If information is missing, say 'cannot evaluate without seeing X'.
Screen: [paste description or OCR text]
Example input:
Screen: dashboard with a 'Delete workspace' button in the top‑right corner, same visual weight as 'Invite'. No confirmation dialog. Error messages appear as a red toast that disappears after 3 seconds.
Output (excerpt):
| Heuristic | Verdict | Trigger | Fix |
|---|---|---|---|
| Error prevention | fail | Destructive action next to primary action, no confirmation | Move to settings, add type‑to‑confirm |
| Visibility of system status | risk | Toast disappears in 3s | Persistent inline error near the field |
| User control and freedom | risk | No undo for delete | Add 10‑second undo snackbar |
Where to verify: the model will happily 'audit' elements you forgot to describe. Treat any verdict about something not in your input as noise.
3. Contrast and accessibility check
For: a quick first pass on color pairs before you open a dedicated contrast tool.
Prompt:
You are an accessibility reviewer. For each foreground/background pair below, compute the WCAG 2.2 contrast ratio (show the formula and the numbers). State pass/fail for AA normal text (4.5:1), AA large text (3:1), and AAA (7:1). Flag pairs that are close to the threshold, because rounding matters.
Pairs:
1. #5A6B85 on #FFFFFF
2. #1A5CFF on #F5F7FA
3. #D92D20 on #FFFFFF
Why it works: the WCAG relative‑luminance formula is deterministic, so the model can do the math — but only if you force it to show the calculation. Without that instruction it tends to guess from memory and get borderline cases wrong.
Where to verify: always confirm the final ratio in a real checker. The model is right on clear cases (dark on white) and unreliable within ±0.3 of the threshold.
4. Component specification for handoff
For: writing the spec that developers need — states, sizes, tokens, edge cases — without a 40‑minute Figma walkthrough.
Prompt:
Write a handoff spec for a [component name] component. Include:
- anatomy (named parts)
- all states (default, hover, focus, active, disabled, loading, error)
- size variants with exact padding and height in px
- which design tokens map to which property
- content rules (min/max label length, truncation behavior)
- accessibility notes (role, aria attributes, keyboard behavior)
- 3 edge cases a developer will hit
Format as Markdown. Use only tokens from this list: [paste token names].
Example output (excerpt):
### Button / Primary
Anatomy: container, label, optional leading icon
States: default, hover (surface darkens to primary-hover), focus (2px ring, offset 2px), disabled (opacity 40%, no pointer events), loading (spinner replaces icon, label stays)
Sizes: sm — height 32px, padding 0 12px; md — height 40px, padding 0 16px
Tokens: background → color.primary; text → color.surface; radius → radius.md
A11y: <button>, aria-busy="true" while loading, Enter/Space triggers action
Edge cases: label longer than 24 chars (truncate with ellipsis); icon‑only variant needs aria-label; disabled button must remain focusable for screen readers if it explains why
Where to verify: pixel values. The model will produce plausible numbers that may not match your Figma file — copy the real values from the inspect panel.
5. Grid and hierarchy critique
For: a second opinion on visual hierarchy before a design review.
Prompt:
You are a senior product designer. I will describe a layout. Critique its visual hierarchy and grid usage. Point out: competing focal points, inconsistent spacing rhythm, misalignment to an 8pt grid, and weak typographic contrast. For each issue, name the element and give a specific fix. Do not suggest changes to content I did not mention.
Layout: [describe columns, spacing values, font sizes, element order]
Example input:
Layout: 12‑column grid, 24px gutter. Hero title 32px/700, subtitle 18px/400, CTA button 16px/600. Card grid uses 20px gaps. Section padding: 40px top, 56px bottom.
Output (excerpt):
- Spacing rhythm: 20px gaps break the 8pt grid — switch to 24px to match gutters.
- Asymmetric padding: 40/56 top/bottom reads as accidental; pick one value or make the difference intentional (e.g., 48/64).
- Hierarchy: subtitle at 18px is only 1.8× smaller than the H1 — increase contrast by dropping to 16px or lightening the weight.
Where to verify: the model can't see your actual rendering, so it critiques the numbers you typed. If you mistype a value, the critique is worthless.
6. Design‑system documentation generator
For: turning a token list and a few component names into readable docs.
Prompt:
Write documentation for a design system based on the inputs below. Structure: principles (3 bullets), color usage rules, typography rules, spacing rules, component inventory table (name, purpose, key states). Tone: concise, imperative. No marketing language.
Tokens: [paste]
Components: [list]
Why it saves time: documentation is the part designers skip. A model can draft 80% of it in one pass, and you edit for accuracy.
Where to verify: every rule the model states must match your actual token set — it will invent a 'primary‑hover' rule even if you never defined that token.
7. UX copy review for microcopy
For: tightening button labels, error messages, and empty states.
Prompt:
Review these UI strings for clarity, consistency, and tone. For each, give the original, a problem (if any), and one improved version. Keep labels under 3 words. Flag any string that uses jargon or blames the user.
Strings: [paste list]
Example:
| Original | Problem | Improved |
|---|---|---|
| 'Submit' | vague, no outcome | 'Create account' |
| 'Invalid input' | blames user, no guidance | 'Enter a valid email' |
| 'Oops! Something went wrong' | no next step | 'Couldn't save. Try again.' |
Where to verify: tone. The model defaults to neutral‑corporate; if your brand voice is informal, add 'tone: friendly but direct' to the prompt.
8. Red‑team your own mockup description
For: finding the questions a developer or PM will ask before they ask them.
Prompt:
I will describe a screen. List the 10 most likely questions a frontend developer would ask during handoff, ordered by blocking severity. For each, note whether the answer is in my description or missing.
Screen: [description]
Why it's useful: this surfaces gaps in your spec before the handoff meeting. In practice, the top three questions are almost always: what happens on error, what happens on empty state, and what happens on slow network.
Where to verify: the model may invent questions about features you didn't design — ignore those, but keep the ones about states you forgot.
9. Token naming convention enforcer
For: keeping a growing token set consistent.
Prompt:
You are a design‑system maintainer. Review this token list and flag naming inconsistencies (camelCase vs kebab‑case, semantic vs raw values, missing scale steps). Propose a corrected list using a single convention: category‑role‑variant (e.g., color‑text‑secondary). Do not rename tokens that already follow the convention.
Tokens: [paste]
Example output:
colorPrimary→color‑brand‑primarygray‑500→color‑neutral‑500spacing‑large→spacing‑32(numeric scale is easier to sort)
Where to verify: renaming tokens breaks Figma Variables and code references. Apply changes in a branch, not on main.
10. Handoff summary for a sprint ticket
For: converting a Figma frame description into a ticket‑ready summary.
Prompt:
Turn this design description into a Jira‑style ticket. Include: summary (one line), context (2 sentences), acceptance criteria (bulleted, testable), out‑of‑scope notes, and open questions. Do not invent requirements that are not in the description.
Design: [description]
Why it works: acceptance criteria are where handoff usually fails — 'button works' is not testable. The model is good at converting vague intent into checkable statements.
Where to verify: every acceptance criterion against the actual mockup. The model will add 'responsive on mobile' even if you never designed a mobile state.
Where the LLM saves time — and where it doesn't
LLMs are genuinely useful for the language layer of design: specs, documentation, microcopy, audit structure, and token naming. They are unreliable for the measurement layer: pixel values, contrast ratios near the threshold, and anything that requires seeing the actual rendering.
The practical workflow is a split: let the model draft the structure, then verify every number in Figma. That's not a limitation to work around — it's a division of labor. The model writes the contract; you check the measurements.
If you want to go deeper into Figma itself, our UI/UX design with Figma guide covers the hands‑on side. And if you're building the developer side of handoff, the web dev lead prompts pair well with these.