How to Design Forms for UX

Forms are one of the most consequential UI elements you'll design. A checkout form, a sign-up flow, a contact form — these are the moments where users either complete an action or abandon it. The decisions you make in form design directly affect completion rates.

Most of what makes a form work well is not creative — it's applying established patterns consistently.

Single-column vs multi-column layouts

Use a single-column layout. Almost always.

Multi-column forms look compact and efficient. In practice, they increase cognitive load and scanning difficulty. Users filling out a form aren't looking at the whole page — they're focused on one field at a time. A second column disrupts that focus and introduces ambiguity about which field comes next.

The exception: side-by-side fields for inherently paired inputs. First name and last name on the same line makes sense — they're a conceptual unit, the labels make the relationship clear, and they're short fields. City and ZIP code work together. Date and time work together.

Everything else: single column.

Keep form width between 480-640px on desktop. Wider than that and text inputs become awkward. Narrower and you're fighting mobile constraints unnecessarily.

Label positioning

Put labels above the field, not beside it or inside it.

Above-field labels are universally recommended for good reasons. They're readable before you click, they're visible while you're typing, and they scale well to mobile widths without the field and label competing for space.

Inline labels (placeholders as labels) seem clean. They're not. Once you've typed in the field, the label disappears — you can't check what the field was asking for without clearing it. For anyone who gets distracted mid-form (which is everyone), this is a problem.

Side labels break on mobile and create issues for longer label text. Don't use them.

One good reason to use placeholder text: to show the format of expected input, not as a label substitute. "MM/DD/YYYY" inside a date field is a useful format hint, not a label. The label above the field still reads "Date of Birth."

Placeholder text that isn't a label

Placeholder text in input fields appears in light gray and disappears when the user starts typing.

Use placeholder text for:

• Format examples: "(555) 555-5555" in a phone number field
• Value context: "Search by name or email" in a search input
• Optional hints: "e.g., Marketing, Design" in a tags field

Don't use placeholder text as the only label. It fails WCAG accessibility requirements (placeholder text doesn't have sufficient contrast and disappears on input), and it's a worse UX regardless of accessibility requirements.

Error messages

Error messages are where most form design fails. The default behavior in most codebases — "This field is required" or "Invalid input" — is not good enough.

Good error messages are:

• Specific: "Enter a valid email address" is better than "Invalid input"
• Actionable: "Password must be at least 8 characters and include a number" beats "Invalid password"
• Placed next to the field: Below the affected field, not in a banner at the top of the form
• In plain language: No technical jargon

Error message pattern for Figma: use a red or error-color text below the input, paired with an icon. The field border should also change color to red. This gives users two visual signals — the border catches attention, the message explains what's wrong.

Don't validate on every keystroke for most fields — it's annoying to see "invalid email" when you've typed just two characters. Validate on blur (when the user leaves the field) or on submit. The exception is password strength, where live feedback as you type is genuinely helpful.

Multi-step forms

When a form has more than 5-7 fields, consider breaking it into steps.

Multi-step forms have better completion rates than long single-screen forms because each step feels manageable. Group fields logically — personal info on one step, preferences on another, payment on the last.

Progress indicators are required. Users need to know how many steps there are and which step they're on. A simple "Step 2 of 4" label is enough. A progress bar with step labels is better.

Save state between steps. Nothing is more frustrating than losing progress because you hit back. If you can't save server-side between steps, save to localStorage. Don't let users lose data they've already entered.

Back navigation must work. Users should be able to go back to previous steps without losing their input in later steps.

Design forms in Figma

Accessibility requirements for forms

These aren't optional — they're legal requirements in many countries and affect real users.

Tab order. Fields should be reachable and completable by keyboard alone. Tab through your Figma prototype to check the logical sequence. The actual implementation must match.

Label association. Every input must have an associated label element in the HTML — not just visually positioned text. For designers, specify this in your handoff: "This label text is the <label> for this <input>, connected via the for attribute." Don't let developers use placeholder text instead of proper labels.

Error announcements. When an error appears, screen readers need to be notified. Specify in your specs that error messages should use aria-live regions so assistive technology announces them.

Color contrast. Input borders, labels, placeholder text, and error messages all need to meet WCAG 2.1 AA contrast ratios. Placeholder text in particular — many designs use too-light gray that fails contrast requirements. Check your colors with a contrast checker.

Touch target size. On mobile, input fields and their associated controls need to be at least 44x44px. This applies to checkboxes, radio buttons, and toggle switches.

Practical Figma patterns

A few component patterns worth building in your Figma design system for forms:

Input field states: Default, focused (highlighted border), filled (with content), error (red border + error message), disabled. Build all five states as component variants.

Label + field + helper text + error: Treat the label, input, helper text (optional usage hint below the field), and error message as a group component. You'll use this pattern repeatedly.

Required field indicators: Pick one convention and be consistent. A red asterisk after the label is standard. Or label optional fields "(optional)" and leave required fields unlabeled — this works when most fields are required.

Forms don't have to be beautiful. They have to be clear, forgiving of mistakes, and fast to complete. Every design decision should serve those three goals.