Design prompts for forms

A form has one job: get the right information with the least friction, and make every step feel answerable. The ones that convert keep a single column with a visible label above each field, ask for only what they truly need, validate inline as you go instead of failing at the very end, design all the field states (focus, error, success, disabled) rather than just the resting one, and end on one button that names the outcome. The prompts below are the most-copied form designs in the Superdesign library, from multi-step wizards and onboarding flows to contact, sign up, checkout and survey forms. 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 form that looks designed, not generated

An AI design agent has a strong default for a form, and most of those defaults add friction: a long stack of required fields, placeholder text used as labels, a multi-column grid, validation that only fires on submit, just the resting field state, and a vague Submit button 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] [type] form for [who fills it] to [the task it completes].
Fields: ask for only [the few you truly need]. Put a visible label above each field, never use placeholder text as the label, and mark optional fields as optional. Do not require a phone number.
Layout: a single column, one field per row, so the eye runs straight down. Group two fields on one line only when they belong together, like city and zip.
Validation: validate inline as the visitor leaves each field, with a specific message that names the fix ("Add the rest, like jane@acme.com"), and include a clear success state after submitting.
Field states: design all of them, the resting, focus, error, success and disabled states, not just the happy path.
Steps: if it is long, break it into a multi-step wizard with a progress indicator, a single logical group per step, and a back button that keeps the data.
Primary action: one solid [button] that names the outcome ("Send message", "Create account"), with a short reassurance line under it. No Reset button.
Style: a neutral base with one [accent] color reserved for focus rings and the primary button. Headline typeface [name], body [name], not the default Inter and no purple gradient.

Labels, not placeholders

Default: It uses placeholder text inside each field as the only label, so the hint disappears the moment you type and you can no longer tell which field is which or check your answers.

Constrain it: Put a persistent label above every field, keep placeholders for examples only, and mark optional fields as optional.

Field count

Default: It asks for everything up front, a long stack of required fields, and makes the phone number required, which has one of the highest abandonment rates of any common field after passwords.

Constrain it: Cap it at the few fields you truly need, never require the phone number, and ask for the rest in a reply or a later step, not at the door.

Single column

Default: It splits the form into a multi-column grid, so the eye has to zig-zag and the order of the fields stops being obvious.

Constrain it: Lay the form out in a single column, one field per row, and group two fields on one line only when they truly belong together.

Inline validation

Default: It checks nothing until you hit submit, then shows one vague red banner and leaves you hunting for which field broke, with no confirmation when things go right.

Constrain it: Validate as the visitor leaves each field, with a specific message that names the fix, and add a clear success state after submitting.

The field states

Default: It styles only the resting field and stops there, so focus, error, success and disabled all fall back to the browser default and look broken.

Constrain it: Ask for all five field states by name: resting, focus, error, success and disabled.

The submit button, color and type

Default: It drops a gray Submit button, often beside a Reset that wipes the form on a misclick, on a purple gradient in the Inter typeface with rainbow accents.

Constrain it: Use one solid button that names the outcome with a short reassurance line, drop the Reset, and name one accent color on a neutral base plus a non-default typeface.

Frequently asked questions

What makes a good form UI?

Low friction and clarity. Keep a single column with a visible label above every field, ask for only what you truly need, validate inline as the visitor goes rather than failing on submit, design every field state, and end on one button that names the outcome. A good form feels answerable, not like a job application.

Should form labels go above the field or inside it as placeholder text?

Above the field. Nielsen Norman Group found that placeholder text used as the only label strains short-term memory and makes it hard to check your answers, because the hint disappears the moment you type. Keep a persistent label above each field and reserve placeholders for an example, like jane@acme.com.

How many fields should a form have?

As few as the task truly needs. Every extra field costs completions, and the phone number field has one of the highest abandonment rates after passwords, so make it optional or ask later. NN/g found compliant forms hit roughly 78 percent one-try submissions versus about 42 percent for non-compliant ones, so trimming fields is the highest-leverage change you can make.

Why does my AI-generated form look generic?

Because a vague prompt gets the model defaults: a long stack of required fields, placeholder text used as labels, a multi-column grid, validation that only fires on submit, just the resting field state, and a gray Submit on a purple gradient in Inter. Name a single column with visible labels, trim the fields, ask for inline validation and all the field states, pick one accent color and a non-default typeface, and it stops reaching for the average.

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

Describe the brief, not the vibe: who fills it and the task it completes, the few fields you actually need with visible labels above them, a single-column layout, inline validation that names the fix plus a success state, all the field states, a multi-step wizard if it is long, one button that names the outcome, one accent color, and a named typeface. 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 fields and brand colors?

Yes. Generate the layout first, then describe your fields, accent color, typeface and copy in plain language and branch a variant. Every design comes back as real, editable code, so wiring in your form handler and brand happens in your own repo, not a rebuild from a picture. Stuck on something? Ping us and we will sort it out together.