By Mehdi HassanWhat are the best practices for web form design?
The best practices for web form design are to ask for less, make each field obvious, validate at the right moment and protect what the user typed. Forms are where SaaS users do real work: sign-up, settings, billing, creating records. They're also where most visible errors happen, so small decisions add up quickly.
Forms are one pattern family inside our broader guide to web app UI design. What makes this guide different is the second half: how to turn design decisions into validation rules that engineering implements exactly, using React Hook Form and Zod. Most form advice stops at the mockup, which is why shipped forms rarely match it.
How many fields should a form have?
A form should have only the fields you need to complete this step, and every other field should be defaulted, inferred or deferred. Before styling anything, run each field through four questions.
Question | If yes | Example |
|---|---|---|
Can we infer it? | Remove the field | Company name from the email domain, timezone from the browser |
Can we default it? | Prefill and let them change it | Currency from the country, the most common plan |
Can we ask later? | Move it to onboarding or settings | Job title, team size, phone number |
Is it optional? | Mark it optional, or cut it | Referral source, notes |
Mark optional fields as "(optional)" rather than starring the required ones. In most product forms nearly every field is required, so labelling the exceptions is shorter and clearer.
How should form fields and labels be designed?
Form fields should have a visible label above them, a size that hints at the expected input, and helper text only when the format isn't obvious. These are the defaults we start from.
- Labels above fields, always visible. Placeholder-only labels vanish as soon as the user types and fail accessibility checks.
- One column. Two columns make people zigzag and skip fields. The exception is tightly related pairs, like first and last name, or city and ZIP.
- Field width matches the input. A ZIP code field shouldn't be as wide as an address field.
- The right input type. Email, tel and number types bring up the right mobile keyboard; autocomplete attributes let browsers fill name, email and address.
- Helper text for formats and constraints, shown before the user makes a mistake: "At least 12 characters."
- Buttons that say what happens. "Create workspace" beats "Submit".
Accessibility isn't a separate pass. Every label must be programmatically tied to its field, errors must be announced, and focus should move to the first error after a failed submit. Our accessible web app design checklist covers the details.
When should inline validation run?
Inline validation should run when the user leaves a field, then update live once that field has shown an error. That timing avoids yelling at people mid-typing while still clearing the error the instant it's fixed.
Before input: show the rule
Helper text explains constraints up front, so users don't have to fail to learn them.
On blur: validate the field
When the user leaves a field, check it. Show a specific message under the field if it fails.
After an error: validate live
Once a field has an error, re-check on every keystroke so the message disappears the moment the value is valid.
On submit: validate everything
Check all fields, show a summary for long forms, and move focus to the first problem.
After submit: handle server errors
Some rules only the server can check (email already used, coupon expired). Map those back to the right field, not a generic banner.
The wording of each message follows the formula from our guide to error state UX: say what's wrong and how to fix it. "Enter an email like name@company.com" is better than "Invalid email".
How do you keep form design and validation rules in sync?
Keep them in sync by writing every rule once, in a schema that both the design spec and the code read from. In React apps we do this with Zod for the rules and React Hook Form for the form state. The designer's spec and the engineer's schema then describe the same thing, field by field.
In practice, the design file lists each field with its type, whether it's required, its constraints and the exact error message. The engineer turns that table into a Zod schema, where each rule carries its message, and passes it to React Hook Form through the Zod resolver. Setting the form's mode to validate on touch gives you the on-blur-then-live behavior described above without custom code.
What the shared spec looks like for a hypothetical sign-up form
Hypothetical example: a three-field sign-up form.
Work email: required, email format. Message: "Enter your work email, like name@company.com."
Password: required, at least 12 characters. Helper: "At least 12 characters." Message: "Use at least 12 characters."
Workspace name: required, 2 to 40 characters. Message: "Name your workspace (2 to 40 characters)."
In code, each line becomes one entry in the Zod object schema, with the message passed to the rule, for example a minimum length of 12 with the message "Use at least 12 characters." React Hook Form reads the schema through the resolver and exposes the errors per field, so the UI shows exactly the copy in the spec. Server-only errors, like an email already in use, are set on the email field after the request returns. Because the schema is the single source of truth, the same rules can also validate the request on the server.
This is one reason we prefer one team owning words, design and code. When the person writing the message is also reviewing the schema, the shipped form matches the mockup, and the error copy isn't rewritten by whoever happened to build it.
When should you use a multi-step form?
Use a multi-step form when the task naturally splits into separate chunks, such as account, company, then billing, and each chunk makes sense alone. Don't split a short form just to make it look smaller. Five fields across three screens adds clicks without reducing effort.
Pros
- Each step feels manageable on long tasks like onboarding or applications
- Earlier steps can shape later ones (skip billing for free plans)
- You can save progress and capture partial completions
Cons
- More clicks and page transitions for short forms
- Users can't see the whole task, so a progress indicator becomes mandatory
- Validation and back-navigation get harder to build correctly
If you go multi-step, show progress ("Step 2 of 3"), validate each step before moving on, keep values when users go back, and save a draft so a closed tab doesn't erase the work. For a full comparison, see multi-step forms vs single-step forms.
What are smart defaults in form design?
Smart defaults are prefilled values chosen because most users would pick them anyway. They cut typing and decisions, but they must be easy to change and never quietly opt users into something they'd object to.
- Good defaults: the user's timezone and country, today's date for a new entry, the last-used project, the most common plan.
- Risky defaults: pre-checked marketing consent, the most expensive plan, auto-renew on add-ons, sharing settings that are public by default.
- Remembered choices: if someone always picks the same report format, make it the default next time.
For AI-assisted forms, a model can draft field values from a pasted document or a short description, then the user confirms. Our guide to inline AI UX patterns covers how to show which values were suggested so users review them rather than trusting them blindly.
