Design prompts for buttons

A button is the smallest thing in your UI and the one users touch the most, so getting it right is mostly about restraint and clarity. The good ones make exactly one action look like the obvious next step, label it with the outcome instead of a vague "Submit", stay solid enough to read as clickable, give a comfortable tap target, and draw every state a real product needs (hover, focus, loading, disabled), not just the resting one. The prompts below are the most-copied button and button-system designs in the Superdesign library, from a rotating light-beam border and a springy jelly press to full neutral, glass, brutalist and 3D button systems with every variant and state on one canvas. Open any one to see the exact prompt behind it, then tweak the copy and generate your own editable version in seconds.

How to prompt a button that looks designed, not generated

An AI design agent has a strong default for a button, and most of those defaults work against the click: a row of equal-weight buttons with no clear primary, generic labels like "Submit" or "Get Started", a flat low-contrast fill that does not read as pressable, a cramped tap target, only the resting state, and the usual Inter on a purple gradient. A good prompt is really a list of constraints that override those defaults. Here is each default you need to override, the words that do it, and a template that bakes them all in.

Design a [light or dark] button [or a button system] for [product], a [what it is] for [who it is for].
Hierarchy: ONE primary action only. Give secondaries less weight as an outline, ghost or text-link variant, never a second solid button of equal weight.
Label: name the outcome, like "Start designing free" or "Save changes", never "Submit", "Get Started" or "Learn More".
Affordance and contrast: a solid fill in one accent on a calm background, clearing WCAG AA 4.5:1, so it plainly reads as clickable.
Target: a comfortable 44 by 44px minimum hit area with spacing between adjacent buttons, so it taps cleanly on a phone.
States: draw them all, default, hover, focus, loading (with a spinner) and disabled, plus an error if the action can fail.
Variants and sizes: [primary, secondary, outline, ghost, destructive, icon] across [small, default, large], all sharing one radius and scale.
Style: a neutral base with one [accent] color reserved for the primary. Typeface [name], not the default Inter, and no purple gradient.

One primary action

Default: It drops a row of buttons of near-equal weight, a Save beside a Cancel beside an Export, so attention splits and nothing reads as the main action. Material Design is explicit that you use only one primary button per view.

Constrain it: Ask for exactly one primary button. Make any alternative a quieter outline, ghost or text-link variant, never a second solid button of equal weight.

A label that names the outcome

Default: It reaches for generic verbs, a gray "Submit", a vague "Get Started" or a "Learn More" that names no outcome, so the user has to guess where the button leads. Nielsen Norman Group warns these labels raise a question instead of answering it.

Constrain it: Make the label name the outcome and finish the headline's sentence, like "Start designing free" or "Save changes", so the user knows exactly what happens next.

Affordance and contrast

Default: Left alone it tints the button a shade of the busy background it sits on, so it reads at roughly 2:1 and looks like plain text, not something you press.

Constrain it: Ask for a solid fill in one accent on a calm background that clears the WCAG AA 4.5:1 minimum, so the button plainly signals it is clickable.

A comfortable tap target

Default: It sizes buttons for a mouse and packs them tight, so on a phone the wrong one gets tapped and motor-impaired users miss far more often.

Constrain it: Require a 44 by 44px minimum target with spacing between adjacent buttons, the touch size Apple and WCAG recommend for reliable taps.

Every state, not just the happy path

Default: It builds only the resting button and silently skips hover, focus, loading and disabled, so the design falls apart the moment a real person interacts with it.

Constrain it: Ask for the states by name: default, hover, focus, a loading state with a spinner, and disabled, plus an error if the action can fail.

Color and type

Default: Left alone it defaults to Inter, a dark theme with a purple gradient, and rainbow accents used as decoration, the house style of a vague prompt.

Constrain it: Name a typeface and one accent color on a neutral base, and reserve that accent for the primary button only.

Frequently asked questions

What makes a good button design?

A good button makes one action look like the obvious next step. It is solid enough to read as clickable, labeled with the outcome instead of a vague "Submit", high enough contrast to clear WCAG AA at 4.5:1, big enough to tap comfortably (a 44 by 44px target), and it draws every state a real product needs: default, hover, focus, loading and disabled. Restraint beats decoration: one clear primary does more than three competing buttons ever will.

How many button styles or variants should I use?

Lead with one primary and let the rest step down in emphasis. Material Design recommends only one primary (filled) button per view, with alternatives as outline, tonal, ghost or text variants so the eye still knows where to go. A practical set is primary, secondary, outline, ghost, a destructive variant for risky actions, and an icon button, all sharing one radius and size scale.

What button states do I need to design?

At minimum default, hover, focus, active or pressed, and disabled, plus a loading state for any action that takes time. Nielsen Norman Group treats these states as how a button communicates that it is clickable and that your interaction registered, and notes a pressed state should appear within 100 to 150ms so people do not tap twice. If the action can fail, draw an error state too.

How big should a button be for touch?

Give it a comfortable hit area. WCAG 2.2 sets a 24 by 24px minimum at Level AA, but the widely recommended touch target is 44 by 44px (Apple Human Interface Guidelines) or 48 by 48dp (Material Design), with spacing between adjacent buttons. Even if the visible button is smaller, padding can make the tappable area reach 44px, which sharply cuts mis-taps on mobile.

Why does my AI-generated button look generic?

Because a vague prompt gets the model defaults: a row of equal-weight buttons with no clear primary, a generic "Submit" or "Get Started" label, a flat low-contrast fill that does not look pressable, only the resting state, and the usual Inter on a purple gradient. Constrain it to one primary action, an outcome-naming label, a solid high-contrast accent on a neutral base, a 44px target, every state drawn, and a named typeface, and it stops reaching for the average.

How do you write a prompt to generate a button UI?

Describe the brief, not the vibe: the product and who it is for, exactly one primary action with any alternative as a quieter variant, a label that names the outcome, one accent color on a neutral base for contrast, a 44px touch target, the full set of states (default, hover, focus, loading, disabled), and the variants and sizes you want. The template above walks through each part, and you can open any example here to see a full prompt that works.

Can I use my own brand colors and typeface?

Yes. Generate the button or system first, then describe your accent color, typeface, radius and label in plain language and branch a variant. Every design comes back as real, editable code, so wiring it into your own components happens in your repo, not a rebuild from a picture. Stuck on something? Ping us and we will sort it out together.