Prompting Basics for Designers

1. 01

   Context

   What you are working with: stack, tokens, system

2. 02

   Task

   What you want done: audit, generate, migrate

3. 03

   Format

   How you want it back: table, code, checklist

4. 04

   Constraints

   Rules to follow: naming, a11y, existing patterns

Reusable prompt pattern

Context + task + format + constraints

• 01 Component spec Props, states, usage, and accessibility notes
• 02 Audit table Issues ranked by severity and suggested fixes
• 03 Token map Semantic tokens matched to UI decisions
• 04 Docs draft Clear usage guidance in your team's voice
• 05 Review checklist Repeatable quality bar for the next pass

The one rule

Be specific. The more context you give, the better the output.

Bad: “Make a button component”

Good: “Create a button component in React with Tailwind CSS. It should have 3 variants (primary, secondary, ghost), 3 sizes (sm, md, lg), support a loading state with a spinner, and be accessible with proper ARIA attributes.”

Set the role before the task

Before you ask for anything, tell the AI who it is. A role primes the model to pull from the right knowledge and hold the right standards for the whole conversation.

You are a senior design systems engineer. You care about
token hygiene, accessibility, and matching existing patterns
over inventing new ones. When something is ambiguous, you ask
before guessing.

That single paragraph changes every answer that follows. Without it, the model defaults to a generic, eager-to-please assistant that invents structure you did not ask for. With it, you get an answer that sounds like a teammate who already knows your bar.

Set the role once at the top of a chat (a system prompt), or paste it as the first line of a one-off request (a user prompt). For work you repeat, save the role as a reusable snippet so you never retype it.

The prompt structure that works

Once the role is set, every good request has four parts. The first three are the floor. The fourth is what separates a usable answer from one you have to clean up.

1. Context (what you’re working with)

I'm working on a design system in Figma with 69 semantic tokens.
The tokens follow a naming pattern: color.{property}.{variant}.
We use Tailwind CSS in the codebase.

2. Task (what you want done)

Audit the current token file and find:
- Tokens that don't follow the naming convention
- Tokens that are defined but never used in any component
- Tokens that are missing descriptions

3. Format (how you want the output)

Return the results as a markdown table with columns:
Token Name | Issue | Suggested Fix

4. Constraints (the rules it must not break)

Constraints:
- Only use tokens that already exist. Do not invent new ones.
- Keep the existing naming pattern. Do not rename anything.
- If a token has no clean match, flag it. Do not force a guess.
- Match the code style already in the file.

Constraints are where most designers lose hours. The model will happily invent a new token scale, rename half your components, or “improve” a pattern you spent a quarter standardizing, all because nothing told it not to. Stating the guardrails up front is faster than catching the damage on the way back.

Design-specific prompt patterns

Generate a component spec

Create a component specification for a [component name].

Context:
- Design system: [your system name]
- Framework: [React/Vue/etc]
- Token system: [your token naming pattern]

Include:
- Props with types and defaults
- Visual states (default, hover, active, disabled, loading)
- Accessibility requirements
- Token usage map
- Usage examples

Audit a Figma file

Look at this Figma component and check:
1. Are all colors using semantic tokens (not raw hex)?
2. Does the spacing follow our 4px grid?
3. Are interactive states complete (hover, active, focus, disabled)?
4. Is the component using Auto Layout correctly?

Flag issues by severity: error, warning, info.

Write documentation

Write component documentation for [component name].

Structure:
- One-line description
- When to use / when not to use
- Props table
- Examples (basic, with icon, loading state)
- Accessibility notes
- Related components

Tone: concise, practical, no marketing fluff.

Design token migration

I'm migrating from [old format] to [new format].

Old structure:
[paste example]

New structure should follow:
[paste target format]

Generate the migration for all tokens. Flag any that can't be automatically mapped.

Prompt modifiers that improve output

Add these to any prompt:

Modifier	Effect
”Be concise”	Shorter, no filler
”Use markdown tables”	Structured output
”Think step by step”	Better reasoning for complex tasks
”Show your work”	Explains decisions
”If unsure, ask before proceeding”	Prevents hallucination
”Follow existing patterns in the codebase”	Consistency

Show an example (the fastest quality jump)

If you only change one habit, change this. Telling the AI what you want is good. Showing it one finished example is better. This is called few-shot prompting, and it is the single most reliable way to control output without writing a longer description.

Instead of describing your naming convention in three sentences, paste one row that already follows it:

Rename these tokens to match our convention. Here is the pattern,
shown by example:

color-bg-surface-default  →  color.background.surface.default
color-text-brand-hover    →  color.text.brand.hover

Now apply the same transformation to the full list below.

The model reads the structure off your example far more accurately than off a rule written in prose. One example beats a paragraph. Two or three examples that cover the edge cases (a nested case, a state variant, an exception) lock it in. This is the same muscle you use when you give a junior designer a reference instead of a spec.

The second prompt matters more than the first

Beginners treat the first answer as the result. Strong prompters treat it as a draft. The skill is not writing one perfect prompt. It is steering across two or three turns.

The first answer almost always misses something: a state you forgot, a token it invented, a tone that is off. Do not rewrite the whole prompt. Point at the specific gap and let the model keep the rest.

First prompt:  Write usage docs for our Button component.

Reply:         [a solid draft, but generic and missing the
               loading state]

Follow-up:     Good structure. Three fixes:
               1. Add the loading state to the examples.
               2. Cut the marketing tone in the intro. Match the
                  plain voice of our existing docs.
               3. The "when not to use" section is too short.
                  Give two concrete anti-patterns.

Each follow-up is short because the context is already loaded. You are nudging, not restarting. When an answer is close but wrong, name the delta. When it is far off, that usually means the role or constraints were missing, so fix those at the top rather than patching the output.

Common mistakes

1. Too vague - “Make it better” tells the AI nothing. Say what “better” means.
2. Too much at once - Break big tasks into steps. One prompt per step.
3. No examples - Show what good output looks like. “Here’s an example of what I want: [paste example]”
4. Ignoring context - Always mention your tech stack, conventions, and constraints.
5. No guardrails - Without constraints, the AI invents new tokens, renames things, and “improves” patterns you did not ask it to touch. Say what it must not do.
6. Quitting after one answer - The first reply is a draft. Name the gap and ask again instead of accepting it or starting over.

Exercise

Rewrite one of your real prompts using the context + task + format structure

15 min

1. Find a prompt you have sent more than once and dissect it

   Open your Claude or ChatGPT history. Find a prompt you have reused (component generation, documentation, audit, rename). Paste it into a document. Underneath, split it into three sections: Context (what am I working with?), Task (what do I want done?), Format (how do I want it back?). Most reused prompts have one of these sections and skip the other two. Fill in the missing sections with real details from your project.

   • Context section names your real stack (framework, token pattern, design system)
   • Task section is a single, specific ask, not a vague “help me with X”
   • Format section specifies structure: table columns, bullet list, code block with language
   • The rewritten prompt is longer than the original (that is the whole point)

2. Run old vs new and compare side by side

   Open two Claude or ChatGPT tabs. Paste the original prompt in one, the rewritten version in the other. Read both outputs. Notice: the new one is more specific, less generic, and easier to use directly. Save the rewritten version as a template. Reuse it next time instead of writing from scratch.

   • The new output is noticeably more usable (fewer “placeholder” sections, more specific to your stack)
   • You can point at at least one sentence in the output that directly reflects something from your Context section
   • You saved the template somewhere reusable (a snippet manager, a file in your vault, a slash command)
   • You deleted the original prompt from your workflow so you never use it again