Skip to main content

Forms Patterns

Forms are how users provide information. Good forms feel effortless; bad forms create friction and abandonment. This document covers form patterns that make data entry as painless as possible.

Last updated: November 2025

Fundamental form principles​

Ask only what you need​

Every field creates friction. Question every field: "Do we truly need this?" If data is optional, remove it from the form entirely rather than marking it optional.

Match fields to the data​

Use appropriate input types. Email fields should trigger email keyboards. Phone fields should trigger numeric keyboards. Date fields should use date pickers.

Provide clear, visible labels​

Labels should be visible and persistent—not placeholders that disappear. Users need to verify their input against the field label.

Show requirements upfront​

Don't surprise users with requirements after they submit. If a password needs special characters, say so before they type.

One column forms

Single-column forms outperform multi-column layouts. The eye path is clear, field relationships are obvious, and responsive behavior is simpler. Multi-column is occasionally justified (city/state/zip), but default to single-column.

Input patterns​

Text fields​

Basic text input: For short, free-form text (names, titles).

  • Use appropriate type attribute
  • Set autocomplete attribute to enable autofill
  • Consider inputmode for mobile keyboards

Email: Use type="email" for validation and mobile keyboard optimization.

Phone: Use type="tel" for numeric keyboard. Don't enforce formatting while typing—accept various formats and normalize on the backend.

Password: Use type="password". Include:

  • Show/hide toggle for verification
  • Clear requirements stated
  • Strength indicator if helpful

Textarea: For multi-line input. Set reasonable height and allow resizing.

Selection inputs​

Radio buttons: For selecting one option from a few choices (2-5). Use when options need to be visible simultaneously.

Checkboxes: For selecting zero or more options. Also for single binary choices (agree to terms).

Select/dropdown: For selecting one option from many (5+). Appropriate when options don't fit as radios. Poor for very long lists—consider autocomplete instead.

Autocomplete/combobox: For selecting from many options with search filtering. Good for long lists, country/city selection, finding items.

Specialized inputs​

Date picker: Use when specific dates matter. Native date inputs work well on mobile. Consider separate fields for contexts needing typing (birthdates).

Time picker: Similar considerations as date. Allow common formats; don't force 24-hour or AM/PM if users expect the other.

File upload: Clear allowed types and size limits. Progress indicator for large files. Preview when useful (images).

Range/slider: For imprecise numeric selection. Show current value. Consider whether exact numbers matter—if so, use a number input.

Validation patterns​

When to validate​

Real-time validation (as user types): Good for format guidance. Risky if too aggressive—don't show errors before user has finished entering.

On blur validation (when leaving field): Good balance. User has indicated they're done with the field.

On submit validation: Always validate on submit as the final check. This catches what other validation missed.

How to validate​

Format validation: Email format, phone format, zip codes. Provide feedback but be lenient—many formats are valid.

Required fields: Mark required fields clearly. Only validate as missing on submit or blur of empty required fields.

Custom rules: Password requirements, username availability. Show requirements proactively, not as errors.

Validation messages​

Be specific: "Password must include at least one number" is better than "Invalid password."

Be constructive: "Enter a valid email address" is better than "Invalid email."

Position near the field: Errors should appear close to the problematic field, not only at the top of the form.

Use color + icon + text: Don't rely on color alone. Include an icon and explanatory text for accessibility.

Error handling​

Inline errors​

Show errors adjacent to the field:

  • Below the field is most common
  • Red border or highlight on the field
  • Error icon for visibility
  • Clear error text

Associate errors with fields programmatically:

<input id="email" aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email</span>

Error summaries​

For forms with multiple errors, also provide a summary:

  • Place at top of form
  • List all errors with links to problematic fields
  • Focus summary on form submission to ensure screen reader announcement

Recovery​

Make fixing errors easy:

  • Don't clear valid fields when there are errors
  • Preserve user input even when invalid
  • Allow correction without re-entering everything
Success states

Don't just show errors—confirm success too. A checkmark when a field is valid builds confidence. A summary confirmation after successful submission closes the loop.

Mobile form considerations​

Touch targets​

Inputs and buttons should be at least 44×44 pixels. Spacing between targets prevents mis-taps.

Keyboards​

Use appropriate input types to trigger helpful keyboards:

  • type="email" → email keyboard with @ symbol
  • type="tel" → numeric phone keyboard
  • type="number" → numeric keyboard
  • inputmode="numeric" → numeric keyboard for inputs that aren't numbers (credit cards)

Autofill​

Enable browser autofill with autocomplete attributes:

  • autocomplete="email", autocomplete="tel"
  • autocomplete="given-name", autocomplete="family-name"
  • autocomplete="street-address", autocomplete="postal-code"
  • autocomplete="cc-number", autocomplete="cc-exp"

Viewport considerations​

Forms should fit within viewport without horizontal scrolling. Test on actual devices—emulators don't reveal all issues.

Progressive forms​

Multi-step forms​

For complex forms, break into logical steps:

  • Show progress indicator
  • Allow back navigation
  • Save progress when possible
  • Keep steps focused (3-5 fields per step)

Conditional fields​

Show fields only when relevant:

  • "Company name" appears only if "I'm registering for a company" is selected
  • Additional details appear based on previous choices

Use smooth transitions—don't jar users with sudden layout changes.

Inline help​

Provide help without leaving the form:

  • Tooltips for brief explanations
  • Help text below fields for important context
  • Expandable help for longer guidance

Anti-patterns to avoid​

Placeholder-only labels​

Placeholders disappear when users type, removing context. Always use visible labels.

Excessive validation​

Don't validate too early, too strictly, or too often. Users need time to enter information.

Reset buttons​

Reset buttons clear all input—rarely what users want. They usually click Reset by accident. Omit them.

All fields required​

If every field is required, you're probably asking for too much. Question each requirement.

Creative layouts​

Non-standard layouts confuse users. Stick to conventional form patterns unless you have strong evidence for alternatives.

Should I use inline validation?

Yes, but carefully. Validate on blur (when user leaves field), not on every keystroke. Don't show errors before the user has had a chance to enter the data.

Required or optional field marking?

Mark whichever is less common. If most fields are required, mark the optional ones. If most are optional, mark the required ones. Never mark both.

How many fields before I need multiple steps?

There's no magic number. If the form feels overwhelming or covers different topics, consider steps. 5-7 focused fields per step is a reasonable guideline.

Should I disable the submit button until the form is valid?

Generally no. Users may not understand why the button is disabled. Better to allow submission and then show clear error feedback.

How do I handle optional fields?

First question whether you need them at all. If you do, mark them '(optional)'. Don't use * for required fields—it's becoming less universally understood.

Related resources