Form Design UX: Rules for Forms People Can Finish

Almost every product depends on a form somewhere: sign-up, checkout, booking, a job application, a contact page. Forms are where users stop browsing and start giving you something – their time, their data, sometimes their money. That is exactly why poor form design costs so much. People abandon it, make mistakes, or call support instead.

The good news is that form design is one of the most rule-friendly areas of UX. Many of the problems are well understood and have been studied for years by groups such as the Nielsen Norman Group. This guide collects the form design rules I find most useful as a UX lead, explains the reasoning behind each, and ends with a checklist. For the HTML side of the same topic, read HTML form best practices alongside this post.

Rule 1: Ask for less

Every field you add is a small task for the user. Before you design the layout, list every field and ask three questions about each one:

1. Do we need it at all? If nobody can name who uses the data, remove it.
2. Do we need it now? A delivery address is needed at checkout, not at account creation. Ask later, when the reason is obvious.
3. Can we get it another way? A PIN code can often suggest the city and state; a logged-in user’s name is already known.

Optional fields deserve special suspicion. If a field is truly optional, many users will skip it anyway, and the ones who fill it in still pay the time cost. Keep optional fields to a minimum and label them clearly as optional rather than marking every required field with an asterisk. When almost everything is required, marking the few exceptions is easier to read.

Rule 2: Use visible labels, not placeholders

Every field needs a label that stays visible while the user types. Placeholder text inside the field disappears as soon as someone starts typing, so people forget what the field was for, cannot check their answers before submitting, and may mistake the grey placeholder for text that is already filled in. Placeholder text is also often low in contrast, which makes it hard to read.

• Put the label above the field. It works on every screen width and keeps the eye moving in one straight line.
• Keep labels short and specific: “Mobile number”, not “Please enter your contact details”.
• Put format hints in a separate line of help text under the label, for example “10 digits, without +91”, where they stay visible.
• Never rely on an icon alone (a phone icon, an envelope) to explain a field.

Rule 3: One column, in a logical order

A single column gives users one clear path from top to bottom. Two columns of fields make people zig-zag, and they often miss a field in the second column. The common exception is a small group of short, closely related fields that people think of as one unit, such as city and PIN code, or expiry month and year on a card.

Order the fields the way people think about the information, not the way your database stores it. Name before address. Address in the order people say it. Payment after the order summary. Group related fields under short headings (“Your details”, “Delivery”, “Payment”) so long forms feel like a few small steps rather than one wall.

Rule 4: Match the field to the answer

The type of input control changes how much effort an answer takes, especially on a phone.

Size each field to fit the expected answer. A PIN code field as wide as the page looks like it wants a paragraph. Also let browsers help: correct input types and autocomplete values let phones offer saved names, addresses and one-time codes, which removes typing altogether.

Rule 5: Validate at the right moment

Validation is where many forms turn hostile. Two timing mistakes are common: showing an error before the user has finished typing (“Invalid email” after the first letter), and showing nothing until they press submit on a long form, then listing ten problems at once.

A balanced pattern that works for most forms:

• Check a field when the user leaves it, not on every keystroke.
• Once a field is showing an error, re-check it as they type, so the message disappears as soon as it is fixed.
• Validate everything again on submit, move focus to the first problem, and show a short summary at the top for long forms.
• Be flexible about formats. Accept spaces in a phone number or card number and clean them up in code instead of rejecting the user.
• Never clear what the user typed when there is an error. Keep their input so they only fix the wrong part.

Rule 6: Write errors that help

A good error message says what went wrong and how to fix it, in plain language, next to the field. Show it with more than one cue – text, an icon and a border colour – so it does not depend on colour alone. That matters for colour-blind users and is part of the WCAG guidance on error identification.

Notice that the helpful messages avoid blame (“you entered wrongly”) and avoid technical words. For more on wording, see UX writing for microcopy.

Here is a small demo of the “check on leave, then re-check while typing” pattern, with an error linked to its field so assistive technology reads it out:

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Inline validation demo</title>
<style>
  body { font-family: system-ui, sans-serif; padding: 24px; max-width: 420px; }
  label { display: block; font-weight: 600; margin-bottom: 4px; }
  .hint { color: #555; font-size: 14px; margin: 0 0 6px; }
  input { width: 100%; padding: 10px; font-size: 16px; border: 1px solid #888; border-radius: 6px; box-sizing: border-box; }
  input[aria-invalid="true"] { border: 2px solid #b00020; }
  .error { color: #b00020; font-size: 14px; margin-top: 6px; min-height: 1.2em; }
  .error:not(:empty)::before { content: "\26A0  "; }
</style>
</head>
<body>
  <label for="mobile">Mobile number</label>
  <p class="hint" id="mobile-hint">10 digits, without +91</p>
  <input id="mobile" type="text" inputmode="numeric" autocomplete="tel-national"
         aria-describedby="mobile-hint mobile-error">
  <p class="error" id="mobile-error" aria-live="polite"></p>

  <script>
    const input = document.getElementById('mobile');
    const error = document.getElementById('mobile-error');
    let touched = false;

    function check() {
      const digits = input.value.replace(/[\s-]/g, '');
      let msg = '';
      if (digits === '') msg = 'Enter your mobile number';
      else if (!/^\d{10}$/.test(digits)) msg = 'Enter 10 digits. You have ' + digits.replace(/\D/g, '').length + '.';
      error.textContent = msg;
      input.setAttribute('aria-invalid', msg ? 'true' : 'false');
    }

    input.addEventListener('blur', () => { touched = true; check(); });
    input.addEventListener('input', () => { if (touched) check(); });
  </script>
</body>
</html>

Rule 7: Make the buttons obvious

• Label the main button with what happens next: “Create account”, “Pay now”, “Book table” – not just “Submit”.
• Make the primary action visually stronger than secondary actions such as “Back”.
• Remove “Reset” or “Clear” buttons. They are easy to press by mistake and rarely needed.
• Do not disable the submit button until the form is valid. Users cannot tell what is missing. Let them press it and then show the errors.
• After submitting, show progress (a loading state) and a clear confirmation, so people do not press twice.

Rule 8: Design for phones and for everyone

Many users in India will fill in your form on a mid-range phone, often on a patchy connection, sometimes in their second or third language. A few habits make a big difference:

• Use a body font size of at least 16px in inputs; smaller sizes can make some mobile browsers zoom in.
• Give fields and buttons generous touch targets and space between them. See mobile app design basics.
• Do not make people type the same information twice. WCAG 2.2 added a success criterion about redundant entry for exactly this reason.
• Allow pasting into password and OTP fields; blocking paste breaks password managers and does not improve security.
• Make sure the whole form works with a keyboard alone, with a visible focus outline. More in web accessibility basics.
• Save progress on long forms so a dropped connection does not wipe everything.

Long forms: split them into steps

For long processes such as a loan application or admission form, a multi-step form with a progress indicator can feel lighter than one long page. Keep each step focused on one topic, show the number of steps (“Step 2 of 4”), let people go back without losing data, and show a review screen before the final submit. Do not split a short form into steps just to look modern; extra pages add clicks and loading time.

Test the form with real people

Form design rules get you most of the way, but only watching people reveals the surprises: a label they misunderstand, a field they cannot answer without looking something up, an error they trigger again and again. A quick round of usability testing with five people filling in your prototype will usually show the biggest problems. If your form is live, look at which fields people abandon on and which errors appear most often in your analytics.

You can prototype realistic form states – empty, focused, filled, error, disabled – with components and variants in Figma; see Figma components and variants. Usability principles such as error prevention and recognition over recall from Nielsen’s heuristics apply directly to form design.

Form design checklist

• Every field has a clear reason to exist and is asked at the right time.
• Optional fields are few and labelled “optional”.
• Every field has a visible label above it; hints sit outside the field.
• Single column, logical order, grouped under short headings.
• Input types and autocomplete match the data (numeric keypad for numbers, saved addresses).
• Errors appear after leaving a field, explain the fix and do not rely on colour alone.
• User input is kept after an error; focus moves to the first problem on submit.
• Main button says what it does; no reset button; no disabled submit.
• Works on a phone, with a keyboard and with a screen reader.
• Tested with at least a few real users.

Frequently asked questions

Further reading

• nngroup.com/articles/web-form-design
• nngroup.com/articles/form-design-placeholders
• nngroup.com/articles/errors-forms-design-guidelines
• w3.org/WAI/tutorials/forms
• w3.org/WAI/WCAG22/Understanding/redundant-entry.html
• developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete