Form design: rules and examples

In short

A form is the point where a product wants something from the user. Sign-up, payment, application or contact: in most products, the real work happens on these screens.

On a form I look at two things: the questions, and what happens when the user gets something wrong. Eight of the 23 rules below are directly about errors.

According to a 2024 Baymard Institute article, 17% of users abandoned checkout because it was too complicated. The same article gives the average checkout as 5.1 steps and 11.3 fields.

When to use the pattern

The pattern applies wherever you ask users for written details. A newsletter sign-up with one field is as much a form as a ten-step loan application.

• Sign-up and sign-in. Few fields, but this is the door users enter the product through.
• Payment and address. Address and card details quickly push the number of fields up.
• Applications and public services. The GOV.UK Design System recommends one question per question page. The reason: users can then focus on that question and their answer.
• Contact and support. Users usually come here with a problem. The form shouldn't make it bigger.

Before I build a form, I ask myself: can I find out this detail without asking the user? If yes, I don't draw the field at all. I settle the order of the fields on paper first, with a rough wireframe.

Form design rules

Each rule is one sentence with a short reason underneath. Where a source stands behind it, I name it; the full details are at the end of the page.

1. Only ask for the fields you really need. Kathryn Whitenton of NN/g advises cutting fields that can be found out another way, asked more conveniently later, or aren't needed at all. According to Baymard's 2024 data, the average checkout has 11.3 fields. Most sites could do with 8.
2. Lay the fields out in one column. According to Whitenton, multiple columns break the path down through the form. Short, related fields such as city and ZIP code may share a row.
3. Group related fields and keep each label close to its field. Whitenton asks for the label to sit close to the field it describes. If it sits between two fields, users have to guess which one it belongs to.
4. Put the label above the field, outside it. Katie Sherwin of NN/g writes that the best solution is a visible label outside the empty field.
5. Don't use placeholder text instead of a label. According to GOV.UK, the placeholder disappears as soon as users start typing, and not every screen reader reads it out. Sherwin adds that users can mistake it for a value already filled in and skip the field.
6. State the format rule before an error happens, outside the field. Whitenton asks for the instruction to be complete when a field needs a specific format. Users shouldn't have to guess password rules. Anyone who only learns the rule from the error message fills in the same field twice.
7. Keep the label short and direct, in sentence case. GOV.UK also says no colon goes at the end of a label. “Email” is enough; “Your email address:” isn't needed.
8. Mark required fields one by one. According to Raluca Budiu of NN/g, a note such as “All fields are required” at the top of a form is easy to miss. She recommends marking every required field, and writes that an asterisk before the label makes scanning easier.
9. If there are only a few optional fields, mark them “optional”. Whitenton advises limiting optional fields to one or two and labelling them clearly. That way users don't learn the rule by trial and error.
10. Size the field to the length of the expected answer. GOV.UK's example: a postcode field is as wide as a postcode. The right size helps people understand what goes in.
11. For two or three options, use radio buttons instead of a dropdown. This recommendation comes from Whitenton. With the options in view, users decide without opening a list.
12. Put the fields in the expected order and keep the tab order the same as the visual order. Whitenton asks you to test the tab order with the keyboard. If the focus jumps around the screen, keyboard users lose their way.
13. Don't show an error while the user is typing. Rachel Krause of NN/g advises waiting until the field is left. According to Baymard, an error shown too early can make users think a correctly entered value is wrong.
14. Put the error message right at the field. According to Krause, users can then read the message while fixing the error. They don't have to remember it.
15. Remove the message as soon as the user has fixed the error. Baymard writes that a message that stays after the fix is confusing, especially with linked fields such as repeating a password.
16. Don't show errors by colour alone. Krause asks for an icon alongside the red colour. WCAG 2.2 criterion 3.3.1 also requires the error to be described in text.
17. Say in the message what happened and how to fix it. GOV.UK advises against general messages such as “This field is required”. For an empty field, write an instruction such as “Enter your name”.
18. Leave blame, apologies and the word “invalid” out of the message. Words such as “forgot”, “please”, “sorry” and “invalid” are on GOV.UK's list of words to avoid. They don't tell users what to correct.
19. If there are errors on submit, show a summary at the top of the form and move the focus there. That's how GOV.UK's validation pattern works. Krause adds that you shouldn't rely on the summary alone, or users have to hunt for every field.
20. Don't wipe anything the user typed. GOV.UK asks for correct and incorrect answers alike to stay in place. Only then can users see what went wrong.
21. Don't put a “Reset” or “Clear” button at the end of the form. According to Whitenton, the harm of accidentally wiping everything is bigger than the benefit for someone who wants to start over.
22. Give fields that collect information about the user an autocomplete value. According to GOV.UK, the browser can then fill in what the user entered before. GOV.UK also writes that this is needed for WCAG 2.2 criterion 1.3.5.
23. Don't make people enter the same information twice in the same process. WCAG 2.2 criterion 3.3.7 requires information already entered to be filled in automatically or available to select.

Do and don't

Bad form and good form

Below are two forms with the same three fields. On the left the bad example, on the right a form that follows the rules on this page. On narrow screens they stack.

Bad form and good form

Bad

Placeholder as label, early error

SendReset

While typing: the field turns red from the first letter. There's no explanation.

After "Send": a general notice appears at the top and every field is cleared. Nothing says the phone number can't contain spaces.

Good

Label on top, error at the field

Full name

Email

I'll reply to this address

Phone (optional)

For example: (503) 555-0142

Send

While typing: no error. The format is checked when you leave the field, and the message disappears as soon as you fix it.

After "Send": a list of problems appears at the top and the focus moves there. Each message sits at its field, and what you typed stays.

Both forms have the same three fields. First leave both empty and press “Send”. Then type “anna@” in the email, enter the phone number with spaces and try again. With JavaScript off, the note under each form describes what happens on send.

You see the difference fastest after "Send". The bad form says "something is wrong" and sends you back to the start. The good one says what's wrong and where to look.

The phone field makes the difference even clearer. The bad form rejects "(503) 555-0142" and doesn't say why. The good one accepts the same format and removes the spaces and brackets itself.

The same logic applies to long numbers such as an IBAN, a card number or a tax ID. People write them in groups. The form should accept those groups and strip the spaces only when saving.

My note

The sources disagree about when to validate inline. NN/g and Baymard recommend checking when the field is left. GOV.UK, on the other hand, asks you to check only when the user presses "Continue" or "Send".

GOV.UK allows checking while typing only on one condition: user research has to show it solves more problems than it creates. GOV.UK's example is the character count.

In the good form above I've combined both. I report an empty field on submit, because the user may still be about to go back to it. A value that's typed but badly formatted, I show when the field is left.

For me, the most expensive form mistake is clearing the fields after an error. GOV.UK also requires fields to be shown again exactly as the user filled them in. Clearing also goes against the ninth of Nielsen's 10 usability heuristics: users should be able to recognise, diagnose and recover from errors.

A note on accessibility

In an accessibility audit, forms are among the first places I look. I start with these four WCAG 2.2 criteria.

• 3.3.2 Labels or Instructions (level A). Wherever users enter something, there has to be a label or an instruction. According to the W3C, a name that's visible only to assistive technologies may not meet the criterion.
• 3.3.1 Error Identification (level A). When an error is detected automatically, the field in error is identified and the error is described in text. According to the W3C, visual cues such as colour may only be used in addition to that text.
• 1.3.5 Identify Input Purpose (level AA). The purpose of a field collecting information about the user has to be machine-readable. The sufficient technique the W3C shows for HTML is the autocomplete attribute.
• 3.3.7 Redundant Entry (level A). If information already entered is asked for again in the same process, it has to be filled in automatically or available to select.

GOV.UK puts an invisible "Error:" prefix before the error message. Screen reader users then hear first that it's an error. The validation pattern also asks for "Error: " to be added before the page title when there's an error.

I describe how I check a form from start to finish in the accessibility audit guide, and all the criteria in the WCAG guide.

A note on implementation

Below is the plain HTML for the email field from the good form. Label, hint and error line are connected to the field through for and aria-describedby.

<form action="/request" method="post" novalidate>
  <div class="field">
    <label class="field__label" for="email">Email</label>
    <p class="hint" id="email-hint">I'll reply to this address</p>
    <!-- Without an error this line stays hidden. -->
    <p class="error" id="email-error" hidden>
      <span class="sr-only">Error: </span>Enter an email address in the format [email protected]
    </p>
    <input class="field__control" id="email" name="email"
           type="email" autocomplete="email" spellcheck="false"
           aria-describedby="email-hint email-error">
  </div>
  <button class="btn btn--primary" type="submit">Send request</button>
</form>

The novalidate on the form turns off the browser's own error bubbles. GOV.UK asks for this and says fields shouldn't get required. That way you write the error text yourself.

Validation in the browser doesn't always work. That's why GOV.UK asks you to always validate on the server too.

On an error I set aria-invalid="true" on the field and remove the hidden attribute from the error line. If you'd like me to build the form for you from design to code, that's what the Design & Ship Sprint is for.

Checklist

Before a form goes live, I go through this list. If you'd like me to check your form against it, the UX Audit covers all of it.

• I can say in one sentence why each field is asked for.
• The fields sit in one column, related ones grouped.
• Every field has a visible label above it; the placeholder isn't a label.
• Format rules are at the field before an error happens.
• Required and optional fields can be told apart.
• No error appears while typing; a fixed error disappears right away.
• Every error sits at its field, with text and an icon.
• On submit a summary appears at the top and the focus moves there.
• No field is cleared after an error.
• Fields with information about the user have autocomplete.
• The tab order matches the visual order.
• Validation also runs on the server.