From Wireframe to Design System: Turning an LLM into Your UI/UX Copilot
Design work rarely suffers from a lack of tools — it suffers from a lack of thinking time. Between mapping user flows, naming buttons, auditing a screen for usability, and keeping a design system consistent, the actual craft gets squeezed into whatever hours are left. A large language model will not open Figma and nudge your auto-layout, but it can absorb the tedious cognitive load around the work: structuring scenarios, drafting UX copy, critiquing a layout, and turning visual rules into tokens.
The trick is that generic prompts produce generic output. "Give me UX advice" returns a listicle. A precise prompt with role, constraints, format, and a concrete input returns something you can paste into Figma, a Jira ticket, or a design-system doc within minutes. Below is a playbook of prompts for the full design lifecycle — from the first user scenario to the handoff. Each one includes the task it solves, the prompt itself, and a short example of what you feed in.
A few ground rules that make all of them work better. Always give the model the context it cannot see: the product, the audience, the platform, the design constraints. Ask for structured output (tables, JSON, numbered lists) so results are reusable. And treat every output as a first draft from a fast, tireless junior — you are still the editor.
1. Screen Inventory From a One-Paragraph Brief
Task: Turn a fuzzy product idea into a concrete list of screens before you touch Figma. This prevents the classic trap of designing a beautiful screen that has nowhere to lead.
Prompt:
You are a senior product designer. Based on the brief below, produce a screen inventory.
Brief: [product, target user, core job-to-be-done, platform].
Output a Markdown table with columns: Screen name
| Purpose (one line) | Primary action | Entry point | Exit points.
Group screens by flow (onboarding, core task, settings, edge cases).
Flag any screen that requires an empty state and a loading state.
Example input: "A mobile app for freelance photographers to send watermarked preview galleries to clients and collect approvals."
You get a table you can drop straight into a Figma page structure or a FigJam board, plus a reminder of empty and loading states many designers forget.
2. User Scenario and Flow Decomposition
Task: Convert a screen list into actual user journeys with decision points and failure paths.
Prompt:
Act as a UX researcher. For the flow "[flow name]" in [product], write the user scenario as a numbered sequence.
For each step include: user goal, action, system response, and one likely failure or friction point.
Then list the top 3 edge cases a designer must handle and suggest how to handle each.
Keep it under 400 words.
This is where LLMs shine: they are good at systematically enumerating what can go wrong. Use the edge-case list as a checklist in your Figma file.
3. Usability Audit From a Screenshot Description
Task: Get a structured critique of a layout. Note: current multimodal models can read images, but a text description forces you to articulate the layout — which is itself useful.
Prompt:
You are a usability auditor applying Nielsen's 10 heuristics.
Here is a description of a screen: [layout, elements, hierarchy, copy, states].
For each heuristic that is violated, write: heuristic name
| what is wrong | severity (low/medium/high) | concrete fix.
Only report real violations; if a heuristic is satisfied, say "OK" in one line.
End with the single highest-impact change.
Nielsen's heuristics are documented by the Nielsen Norman Group (nngroup.com) and remain a practical audit framework. Feeding the model a named framework keeps the critique grounded instead of hand-wavy.
4. Design Tokens and System Skeleton
Task: Draft a token structure and component inventory that a design system can grow from.
Prompt:
You are a design systems architect. For a [product type] with brand colors [hex list], propose:
1. A three-tier token model (primitive → semantic → component) as a table: token name
| value | usage.
2. A component inventory grouped by category (inputs, navigation, feedback, data display), each with the states it needs (default, hover, focus, disabled, error).
3. Three naming rules to keep tokens consistent.
Use the W3C Design Tokens Community Group naming style (dot notation, e.g. color.text.primary).
The W3C Design Tokens Community Group publishes a format specification (designtokens.org) that many tools now align with, so dot-notation naming will map cleanly to real pipelines later.
5. UX Microcopy and Button Labels
Task: Write interface text that is clear, consistent, and human — the part designers often improvise at 11 p.m.
Prompt:
You are a UX writer. For each element below, write copy in [tone: friendly/professional], max [N] characters.
Elements: [button labels, empty state, error message, confirmation dialog].
For each, give: recommended copy
| a shorter alternative | why it works in one sentence.
Avoid jargon and blame in error messages; state what happened and what to do next.
Example: Empty state for a photo gallery → "No galleries yet. Create your first one to share previews with a client." The model will also propose a shorter variant and justify the choice — useful when you must defend copy in review.
6. Accessibility Pass Before Handoff
Task: Catch contrast, labeling, and focus-order issues early.
Prompt:
Review this screen against WCAG 2.2 AA. Input: [elements, colors, interactions].
List only potential failures as a table: criterion (e.g. 1.4.3 Contrast)
| issue | fix.
Then give a 5-item pre-handoff accessibility checklist for the developer.
WCAG 2.2 is a W3C Recommendation (w3.org/TR/WCAG22/), so referencing the exact criterion numbers keeps the feedback verifiable rather than vague.
7. Layout and Hierarchy Critique
Task: Pressure-test visual hierarchy and spacing logic.
Prompt:
You are an art director reviewing a layout. Input: [grid, spacing scale, element sizes, primary action].
Answer in three parts: (1) does the visual hierarchy match the intended primary action? (2) where is spacing inconsistent with an 8pt scale? (3) two specific changes to improve scanability. Be concrete: name elements and values.
Specificity is the whole game — "make it cleaner" is useless, "increase the gap between the title and body from 8 to 16px" is actionable.
8. Handoff Notes for Developers
Task: Turn a finished mockup into a spec developers can build without a call.
Prompt:
Convert this screen into a developer handoff spec. Input: [screen description, components, states].
Output: component tree
| props and variants | interaction states | responsive behavior at [breakpoints] | edge cases (long text, missing data) | open questions for the designer.
Format as Markdown sections, ready to paste into a ticket.
The "open questions" section is quietly the most valuable — it surfaces the ambiguities that cause rework.
9. Consistency Checker for a Design System
Task: Audit a set of components for drift — the slow divergence that erodes every design system.
Prompt:
Here is a list of components with their variants and tokens: [paste].
Identify inconsistencies: duplicate components, mismatched naming, missing states, one-off values not tied to tokens.
Output a table: issue
| affected components | recommended fix | priority.
Run this after every major feature push. It is faster than eyeballing a Figma library and catches the small stuff.
10. Competitive UX Teardown
Task: Quickly compare how competitors solve the same problem.
Prompt:
Compare how [competitor A], [competitor B], and [competitor C] handle [specific task].
For each: number of steps, key UI pattern, friction point.
Then recommend one pattern to adopt and one to avoid, with reasoning.
Base this only on what I describe below; do not guess features you are not given.
The last line matters — it stops the model from inventing features. Feed it real observations from your own product research.
11. Design Critique Facilitation
Task: Prepare a structured critique session so feedback is useful, not personal.
Prompt:
Draft an agenda for a 30-minute design critique of [feature]. Include: context setting (2 min), the design question (1 min), silent review (5 min), structured feedback using "I like / I wish / what if" (15 min), decisions and owners (7 min).
Add three prompts to steer feedback toward user goals rather than taste.
This turns critique from a vibe check into a repeatable process — and the model does the boring facilitation prep.
Where This Leaves You
An LLM will not replace your judgment, your taste, or your Figma skills. What it will do is compress the invisible labor — the scenario mapping, the copy drafts, the audit checklists, the handoff notes — into minutes instead of afternoons. The prompts above are starting points: the more context you give (audience, constraints, named frameworks like Nielsen's heuristics or WCAG 2.2), the sharper the output.
Pick two or three that match your current bottleneck, run them on a real screen this week, and keep the ones that save you time. The best prompt is the one you actually reuse — so build a small personal library, tweak the wording to your product, and let the copilot handle the busywork while you focus on the design decisions only you can make.
Comments