Best AI Prompts for Designers

AI summary

Seven AI prompts for product, brand, and UX designers: brief translation, critique self-review, design system component specs, user flow drafting, copy audits, stakeholder walkthroughs, and engineering hand-off docs. Built to keep the visual judgment yours while AI handles the structuring around it.

Prompt 1

Brief-to-Direction Translator

Clients write briefs that hide what they actually want. This prompt translates the brief into design direction you can use.

Here is a design brief I received:

[PASTE THE BRIEF]

Client context: [WHO THEY ARE, WHAT THEY DO, WHY THIS PROJECT MATTERS NOW].
What I have seen them respond well to before (if returning client): [PRIOR WORK PATTERNS].

Translate the brief:

1. THE STATED GOAL: restate the client's goal in plain English.
2. THE UNSTATED GOAL: what the client probably actually wants that they did not articulate.
3. THE AUDIENCE: who the design is for, beyond the client's description.
4. THE TONE: 3-5 adjectives that should anchor the design, with the reasoning.
5. THE REFERENCES TO LOOK AT: 3-5 directional references (named only by category and characteristics, not specific designer or brand citations).
6. THE QUESTIONS TO ASK BEFORE STARTING: 3 questions that would meaningfully change the direction if answered differently.

Do not invent client preferences I have not described. Do not assume a brand voice the brief did not specify.

When to use: Within 48 hours of receiving the brief. · Best model: Claude. The discipline about “do not invent preferences” matters.

Prompt 2

Critique-Ready Self-Review

Before you bring work into a critique, this prompt finds the obvious issues so the crit can focus on the hard ones.

I am about to share this work in a design critique:

[PASTE OR LINK TO THE DESIGN. If pasted, describe the layout in detail: what is where, what hierarchy is intended, what state is shown.]

The brief for this work: [REMIND THE GOAL]
The audience: [TARGET]
What I am uncertain about: [WHERE YOU ARE STUCK]

Review as the most thoughtful senior designer on the team:

1. HIERARCHY: does the eye land where it should first, second, third.
2. CONTRAST AND ACCESSIBILITY: any obvious WCAG concerns I should fix before the crit.
3. ALIGNMENT AND SPACING: any irregular rhythm that distracts.
4. TYPE: pairings or hierarchy that fight the content.
5. THE COPY: does the layout serve the words, or is the layout fighting them.
6. THE ONE THING I AM CLEARLY MISSING: not subjective; the thing a reviewer is going to ask about first.
7. THE QUESTION I SHOULD POSE in the crit to get useful feedback (not "what do you think").

Do not redesign the work. Surface the issues. I will fix.

When to use: 30 minutes before any design crit. · Best model: Claude or any visual-capable model. For complex visuals, paste a screenshot.

Prompt 3

Design System Component Spec

You are about to add a component to the design system. This prompt produces the spec so engineering does not ask 20 questions during implementation.

I am adding [COMPONENT NAME] to our design system.

What it does in plain English: [ONE-LINE PURPOSE]
Where it is used: [LIST USE CASES]
Visual states (default, hover, active, disabled, loading, error, etc.): [LIST]
Variants (sizes, colors, icon left/right, etc.): [LIST]
Does it depend on or relate to existing system components: [LIST]

Draft a component spec with:

1. PURPOSE: 2 sentences a junior engineer can read without questions.
2. ANATOMY: the visual parts of the component with names ("label," "icon-leading," "helper-text," etc.).
3. PROPS / VARIANTS: every variant a developer would code, with default values.
4. STATES: every state with the visual rule.
5. INTERACTION: how the component responds to user actions.
6. ACCESSIBILITY: keyboard, ARIA, focus, contrast notes.
7. SPACING AND SIZING: the rule for how this component sits in layouts.
8. WHAT IT IS NOT: explicit list of use cases this component should not be used for.
9. THE 3 QUESTIONS an engineer will ask when implementing; answer each.

Do not invent design tokens or component names from other systems. Use only what I provided.

When to use: Before opening a component PR in the design system repo. · Best model: Claude. The discipline about not inventing tokens matters.

Prompt 4

User Flow from Goal

Most user flow diagrams start with “how should the screen work?” The wrong question. This prompt starts with “what is the user trying to do?” and works backwards.

I need to design a flow for [FEATURE].

The user's goal in their own words: [GOAL]
The context they enter the flow in: [BEFORE STATE]
The success state they should reach: [AFTER STATE]
Known technical constraints: [WHAT THE SYSTEM CAN AND CANNOT DO]
Known business constraints: [WHAT WE WILL AND WILL NOT DO]

Produce a flow with:

1. THE SHORTEST PATH: the fewest steps that get the user from before to after.
2. THE BRANCHES: the 2-3 most likely places the user diverges or hesitates, and what the flow does at each.
3. THE ERROR STATES: every place the system could fail, and the recovery path.
4. THE FIRST-TIME vs RETURNING USER difference: what changes when the user has done this before.
5. THE EXIT POINTS: where users leave without finishing, and whether that is OK or a problem.
6. THE METRIC: how we would know in two weeks if the flow is working.

Return the flow as a numbered list of steps with branching noted. Do not draft mock UI; the flow comes first.

When to use: Day one of a new feature, before any pixels. · Best model: Claude (most disciplined about staying flow-level instead of jumping to mockup language).

Prompt 5

Copy Audit for a Screen

Most design work has too many words. This prompt cuts the screen’s word count by 30 percent without losing meaning.

Here is the copy on a screen I am working on:

[PASTE ALL TEXT FROM THE SCREEN: page title, section headers, body, button labels, helper text, error states, empty states, etc.]

The purpose of this screen: [ONE SENTENCE]
The audience: [WHO IS READING THIS]

Audit the copy:

1. WORD COUNT: current total, suggested target.
2. WORDS TO CUT: every word that does not earn its place.
3. PHRASES THAT REPEAT: where the same idea is said twice in different words.
4. UNCLEAR TERMS: any jargon or insider language a first-time user would not know.
5. THE TONE: is it consistent across the page, or does the header feel different from the button.
6. THE REWRITE: shortened versions of the top 3 problem sections, in my voice.
7. THE MISSING PIECE: if there is information the user needs that is not on the screen, name it.

Do not propose a complete rewrite. Surface the cuts and clean the worst 3 sections. I will rewrite the rest.

When to use: Mid-fidelity stage, before development hand-off. · Best model: Claude. ChatGPT also works but tends to add words instead of cutting them.

Prompt 6

Stakeholder Walkthrough Drafter

You have to present design work to an exec who has not been in the weekly review. This prompt drafts the walkthrough.

I am about to walk [STAKEHOLDER ROLE] through my current design for [PROJECT].

What they care about most: [SPECIFIC PRIORITIES]
What they probably do NOT care about (do not waste time on): [LIST]
The one decision I am asking them to make or input on: [SPECIFIC ASK]
The state of the design: [EXPLORATION / NARROWED / READY-FOR-FINAL]

Draft a 7-minute walkthrough with:

1. THE 30-SECOND OPENING: where I name the problem and the goal in plain English (not designer language).
2. THE PATH I TOOK: 2 sentences on what I considered and rejected, so they trust the recommended direction.
3. THE RECOMMENDED DIRECTION: walked through with the user's experience as the through-line, not the screens themselves.
4. THE OPEN QUESTIONS: what I need them to weigh in on, framed as choices not opinions.
5. THE THINGS NOT TO DISCUSS NOW: aspects that will distract from the decision I need.
6. THE CLOSE: what happens next, with the next checkpoint.

Write it as a script I would speak from, not slides. Avoid designer jargon ("affordance," "density," "chunking") with non-designer audiences.

When to use: The day before the walkthrough. · Best model: Claude. Audience-translation discipline matters for stakeholder work.

Prompt 7

Hand-Off Doc for Engineering

Most hand-off docs read like art history. Engineers want a different doc. This prompt produces what they actually need.

I am handing off this design to engineering:

FEATURE: [FEATURE NAME]
LINK TO FIGMA OR FILES: [LINK]
KEY SCREENS: [LIST]
NON-OBVIOUS INTERACTIONS: [LIST]
DEPENDENCIES (new components, existing components used, copy that lives elsewhere): [LIST]
KNOWN UNKNOWNS (things I deferred or punted): [LIST]

Draft an engineering hand-off doc with:

1. WHAT THIS FEATURE DOES: 2 sentences a backend engineer who has never seen the feature can understand.
2. SCREENS AND STATES: a flat list of every screen state engineering must implement.
3. COMPONENTS USED: list new vs existing, with link or anchor to each.
4. INTERACTIONS: every interaction that is not obvious from the static design.
5. RESPONSIVE BEHAVIOR: how the layout adapts across breakpoints.
6. ACCESSIBILITY: keyboard, ARIA, focus, contrast, screen-reader notes.
7. EDGE CASES: empty state, error state, loading state, max-content state.
8. WHAT I DECIDED AND WHY: 2-3 design decisions worth noting so engineering does not relitigate them.
9. WHAT IS STILL OPEN: anything I deferred for a follow-up.

Avoid design jargon. Engineers should be able to read this and start coding without DM'ing me.

When to use: On the day you mark the design “ready for development.” · Best model: Claude is well-suited because it does not over-explain things engineers already know.

Connectors are now standard

Claude, ChatGPT, and Grok all support connectors that let your AI read live data from your work tools (Gmail, Notion, GitHub, Asana, HubSpot, Stripe, and many more) instead of relying on you to paste context. For designers this means the AI can read your Figma file metadata, your Notion design ops wiki, your Google Drive folder of references, your Gmail thread with the client, or your Linear/Jira ticket for the design task.

For designers, the connectors worth pairing with these prompts:

Get Smarter About AI Every Morning

Free daily newsletter. Built for people who want to use AI well, not chase every model.

Free forever. Unsubscribe anytime.

Two ways to go further