Your Second Pilot in Figma: 12 Prompts That Build a Design System, Write UX Copy, and Hand Off to Dev — No Designer Required
Every product team hits the same wall. A feature needs a screen by Friday, the designer is booked on a different squad, and the frontend engineer is staring at a blank Figma canvas wondering where the 8px grid went. In 2026 that wall is thinner than it used to be — not because LLMs can "design," but because they are excellent at the boring, structured work that surrounds the actual pixels: naming tokens, drafting interface strings, auditing flows against heuristics, and writing the spec that saves a three-day Slack thread.
This roundup is a working toolkit, not a theory piece. Each prompt below is written to be pasted into ChatGPT (or Claude, or any capable model) alongside a screenshot, a JSON export, or a short description of your screen. I use the task → prompt → example result format so you can see what to expect before you spend tokens. Treat the model as a co-pilot with no taste and infinite patience: it will never have your product's voice, but it will happily generate twelve naming variants of a spacing scale while you decide which one fits.
One honest caveat before we start: a language model cannot see your Figma file unless you show it. Screenshots, exported JSON from the Figma API, or pasted CSS all work. Everything below assumes you feed the model real material — vague prompts get vague answers, and that is a design problem, not a model problem.
1. The Screen Skeleton: From Feature Brief to Wireframe Structure
Task: Turn a one-paragraph feature description into a structured layout hierarchy before you touch Figma. This front-loads the information architecture so you don't rebuild the frame three times.
Prompt:
You are a senior product designer. Here is a feature brief:
"Users of a B2B invoicing tool need to see overdue invoices and send reminders."
Produce a screen structure as an indented outline with these levels:
1. Page purpose (one sentence)
2. Primary action (single)
3. Content blocks in visual priority order
4. For each block: the data it displays and its empty state
5. Any secondary actions
Do not propose colors or fonts. Structure only. Flag anything ambiguous
in the brief as an open question at the end.
Example result: The model returns a hierarchy where the overdue-invoices table is the primary block, a bulk "Send reminder" action sits above it, and it flags the ambiguity: "Does 'overdue' include partial payments?" That single question often prevents a rework cycle.
2. Design Tokens as JSON: Naming Scale Without the Guesswork
Task: Generate a consistent token set you can import into Figma Variables or a Tailwind config. The model is good at this precisely because it is boring and systematic.
Prompt:
Generate a design token set as JSON for a neutral B2B SaaS product.
Requirements:
- Spacing scale on a 4px base: 0,1,2,3,4,6,8,12,16,24,32,48,64
- Radii: none, sm, md, lg, full
- Color roles (not hex names): background, surface, border, text-primary,
text-muted, accent, accent-hover, danger, success
- Font sizes with line heights, modular scale 1.25 from 14px
Output valid JSON with two top-level keys: "global" and "alias".
Use semantic names, never "blue-500" style names.
Example result: You get a global block of raw values and an alias block mapping roles to globals — the same two-tier pattern the W3C Design Tokens Community Group describes in its draft specification. Import the JSON into Figma Variables via a plugin, and your spacing is consistent across every frame before you draw a single rectangle.
3. Component Inventory Audit
Task: Paste your existing component names and let the model find duplicates, orphans, and naming chaos.
Prompt:
Here is a list of component names from a Figma library:
Button/Primary, Btn-Secondary, button_tertiary, Card, CardV2, CardContainer,
Input, TextField, input_field_OLD, Modal, Dialog, Popup...
Group them by real intent, identify duplicates and near-duplicates,
and propose a naming convention. Then output a table:
| Current name | Proposed name | Action (keep/merge/rename/deprecate) |
Be ruthless about deprecation — list anything that should die.
Example result: A Markdown table that collapses Modal, Dialog, and Popup into one Overlay/Dialog component and flags CardV2 as a merge candidate. This is the fastest component-audit pass you will ever run.
4. UX Copy: Rewriting Interface Strings in Your Voice
Task: Rewrite button labels, errors, and empty states so they are consistent and human. This is where LLMs shine — they generate variants faster than any human can brainstorm.
Prompt:
Rewrite these UI strings for a friendly but professional B2B product.
Rules:
- Buttons: verb + object, max 3 words
- Errors: say what happened, why, and what to do next
- No exclamation marks, no "Oops", no blame
Return a table:
| Context | Original | Rewritten | Why |
Strings:
1. Button: "Submit"
2. Error: "Error 422"
3. Empty state: "No data"
4. Toast: "Saved successfully!"
Example result: "Submit" becomes "Send invoice", "Error 422" becomes "We couldn't save this invoice — the amount field is empty. Add an amount and try again." The "Why" column is the valuable part: it teaches your team the rule, not just the fix.
5. Microcopy for Every State of a Component
Task: Most handoffs break because nobody wrote the loading, empty, error, and success states. Make the model enumerate them.
Prompt:
For a "Recent invoices" list component, write microcopy for every state:
loading, empty (first use), empty (filtered, no results), error (network),
error (permission), partial data, and success after refresh.
For each: a headline (max 6 words) and one supporting line (max 20 words),
plus a suggested action label if applicable. Output as a table.
Example result: Seven rows you can paste straight into Figma frames as text layers. The distinction between "empty on first use" (onboarding tone) and "empty after filtering" (neutral tone) is the detail that separates a polished product from a demo.
6. Heuristic UX Audit of a Screenshot
Task: Run a structured critique against Nielsen's ten usability heuristics — a real, published framework from the Nielsen Norman Group, not an invented checklist.
Prompt:
Attached is a screenshot of an invoice list screen.
Audit it against Nielsen's 10 usability heuristics.
For each heuristic that is violated:
- Name the heuristic
- Point to the specific element in the screenshot
- Explain the user impact in one sentence
- Suggest a concrete fix
Skip heuristics that pass. Rank issues by severity (high/medium/low).
Example result: The model typically catches missing visibility of system status (no indication a reminder was sent) and weak error prevention (bulk delete with no confirmation). Treat it as a first-pass reviewer, not an oracle — you still decide what matters.
7. Accessibility Pass: Contrast and Semantics
Task: Catch the accessibility issues that ship silently. The model can reason about WCAG 2.2 success criteria (a W3C Recommendation) if you give it concrete values.
Prompt:
Here are color pairs from a design:
- text #767676 on background #FFFFFF
- text #FFFFFF on accent #4A90D9
- border #E0E0E0 on surface #F5F5F5
For each pair, estimate the contrast ratio and check it against
WCAG 2.2 AA for normal text (4.5:1) and large text (3:1).
Output a table:
| Pair | Est. ratio | AA normal | AA large | Verdict |
Note that estimates may be off — recommend verification in a contrast checker.
Example result: A table flagging #767676 on white at roughly 4.5:1 — borderline — and #FFFFFF on #4A90D9 failing AA for normal text. The model's arithmetic can drift, so always confirm the final numbers in a real contrast tool before locking tokens.
8. Responsive Behavior Spec
Task: Define how a layout reflows before dev asks. This turns a static frame into a rule set.
Prompt:
A dashboard has: a left sidebar (240px), a top bar (64px),
a main content grid of 3 cards per row, and a right activity panel (320px).
Write responsive behavior rules for breakpoints 1440, 1024, 768, 375.
For each breakpoint, specify: sidebar state, activity panel state,
card columns, and any elements that collapse into menus.
Output as a Markdown table.
Example result: A four-row table where the sidebar collapses to icons at 1024 and to a drawer at 768, and the activity panel becomes a tab at 375. Hand this to a frontend engineer and most "how should this behave on mobile?" questions evaporate.
9. The Handoff Spec: From Frame to Developer Ticket
Task: Generate the specification document that normally lives in someone's head. This is the single highest-leverage prompt in the list.
Prompt:
Write a developer handoff spec for the "Send reminder" flow.
Include:
1. Flow summary in 3 sentences
2. Screen-by-screen description with component names
3. All states per screen (default, loading, success, error)
4. Interaction details: what triggers what, debounce, confirmation
5. Data the frontend needs from the API (fields, not endpoints)
6. Edge cases and open questions
Format as Markdown with headings per screen. Be terse — devs hate prose.
Example result: A ticket-ready Markdown doc with a per-screen state table and an explicit "Open questions" section. Paste it into Jira or Linear, attach the Figma link, and the handoff meeting shrinks to a comment thread.
10. API-to-UI Contract Check
Task: Verify the design doesn't assume data the backend can't deliver. Engineers love this one.
Prompt:
Here is a JSON response shape from the invoices endpoint:
{ "id": "...", "amount": 1200, "currency": "EUR", "due_date": "2026-10-01", "status": "overdue" }
And here is what the UI needs to display: customer name, invoice number,
amount with currency, days overdue, and a reminder-sent badge.
List every UI field that is NOT covered by the response,
and suggest whether to extend the API or compute client-side.
Example result: The model flags that customer name, invoice number, and reminder-sent are missing, and proposes computing days overdue client-side from due_date. That is a five-minute conversation that prevents a mid-sprint blocker.
11. Design System Documentation Generator
Task: Turn a token file and component list into readable docs, so the system is usable without a designer explaining it.
Prompt:
Given this token JSON and component list, write documentation pages:
1. "Getting started" — how to use tokens in Figma and in code
2. One page per component family with: purpose, anatomy,
do/don't examples as text, and accessibility notes
Keep each page under 300 words. Use plain language.
Example result: A docs skeleton you paste into Notion or a Storybook MDX file. The do/don't sections are especially useful — they encode the judgment calls that usually live only in a senior designer's head.
12. The Final QA Checklist Before Handoff
Task: A last-pass checklist that catches the things everyone forgets. Run it on every frame before you mark a ticket "ready for dev."
Prompt:
Act as a design QA reviewer. Given this screen description,
produce a pre-handoff checklist covering:
- All states designed
- Text content final (no lorem ipsum)
- Tokens used, no hardcoded hex
- Accessibility notes present
- Responsive behavior defined
- Empty and error states written
- Naming consistent with the design system
Output as a checklist with pass/fail placeholders.
Example result: A reusable checklist you can literally copy into your PR template or Figma page. Teams that run it consistently report fewer "this wasn't in the mockup" round-trips — because the mockup now answers the question.
What This Actually Changes
None of these prompts will make a language model a designer. What they do is remove the friction that surrounds design work: the naming debates, the missing states, the handoff documents nobody wants to write. A model is a tireless junior who never gets bored of enumerating edge cases and never takes it personally when you reject nine of ten naming suggestions.
The pattern that matters is the loop: structure first, tokens second, copy and states third, spec last. If you adopt only one habit from this article, make it prompt #9 — the handoff spec. It is the cheapest way to turn a static Figma frame into something a frontend engineer can actually build without a meeting. Try it on your next ticket and see how much of the Slack thread never happens.
And remember the golden rule of AI-assisted design: garbage in, garbage out. Feed the model real screenshots, real JSON, and real constraints, and it will return real work. Feed it vibes, and you will get vibes back — beautifully formatted, and completely useless.
Comments