Skip to main content

Form design

Best practice, research insights and examples

Here's my best practice guidelines for form design.

Working on a design system for a bank taught me a lot about forms. I watched testing in labs. I worked alongside experts from specialist accessibility organisations. I saw forms tested by people with disabilities and users of assistive technology. I've also read a lot of research.

From all this learning I've formed my own forms best-practice guidelines. I thought it would be useful start recording it. Here's my work in progress. I do UI/UX so I'm coming at this from a designer's perspective.

👋 Hey, I haven't updated this page in a while 👋

I stand by the advice but the insights are a little tired. Use at your own risk! If you want current form advice, head over to form expert Adam Silver's blog.

First, some principles

It's important to start with with a set of principles. It's easy to become swayed by design trends and I have to bring myself back to the user.

I aspire to the Inclusive Design Principles. Designing forms for people experiencing permanent, temporary or situational disabilities improves the experience for everyone. I also look to the WCAG principles. Your website or app must be:

  • perceivable
  • operable
  • understandable
  • robust and compatible

In summary, think of your user and keep things as simple and as functional as possible. But don't overvalue simplicity and style at the cost of clarity. In the words of Luke Wroblewski "obvious always wins".

Back to top ↑

Text input

Simple input for a form. Easy to overcomplicate.

My guidelines

  • Text input fields must have a visible label above the input box.
  • Don't rely on placeholder text. It is not a substitute for a label.
  • Place hint text under the form label.
  • The size of the input box should reflect the intended input.
  • Unless labelled otherwise, all fields in a form are required. Mark optional fields as 'optional'.
Graphic of a form input box

Research insights and sensible thinking

☞ Placeholders

☞ Labels

☞ Layout

Accessibility considerations for text input

Text fields in the wild

The component gallery: Text input

Back to top ↑

Buttons

Buttons trigger an action or event such as continuing to the next stage or submitting a form. Use them purposely.

My guidelines

  • Button text should describe the action the button performs and be consistent through the journey.
  • Don't overload the user with choices. Use only one primary button on each page for the main action.
  • Place the submit button where users look for it. In a standard form journey this is usually to the left edge of the form, directly below the final field.
  • Make destructive buttons like cancel or previous harder for the user to find. A back button or link often works well above the form.
  • Avoid disabled buttons. They have poor contrast and can cause confusion.
Graphic of a form field with a left aligned continue button

Research insights and sensible thinking

Accessibility considerations for buttons

  • Button text needs a 4.5:1 contrast ratio against the button container colour. WCAG 1.4.3
  • Button container needs a 3:1 contrast ratio against the background. WCAG 1.4.11
  • When speccing out a button, remember to include a design for all the states; default, focus, hover, active. All states need sufficient colour contrast.

Buttons in the wild

The component gallery: Buttons

Back to top ↑

Radio buttons

I like big radio buttons (and I cannot lie). They show all available choices upfront. Use a radio group when the user can only select one option from a list.

My guidelines

  • Position radio buttons to the left of the label and stack options vertically.
  • Users can only select one option but don't assume that they will know this.
  • Once an option has been selected the user can't unselect it without refreshing their browser. Consider adding a 'none' option.
  • Order radios from most to least common options. If this will cause an unwanted bias, order options alphabetically.
  • Place hint text under the form label.
  • Make radio buttons easy to tap, with a target height of at least 44 pixels.
  • Radio buttons must ALWAYS be round.
Graphic of a form radio button group

Research insights and sensible thinking

Accessibility considerations for radio buttons

  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3
  • Radio button outline and fill needs a 3:1 contrast ratio against the background. WCAG 1.4.11
  • For an accessible label, group radio buttons together in a field set and legend that describes them.
  • Selecting a radio button must not cause anything surprising to happen like submitting a form, significantly changing the content on the page, or moving the keyboard focus. WCAG 3.2.2

Radio buttons in the wild

The component gallery: Radio buttons

Back to top ↑

Checkboxes

Use a checkbox to select multiple items, they show all choices upfront. Users are generally familiar with the affordance of checking a box.

My guidelines

  • Position checkboxes to the left of the label and stack options vertically.
  • Make it clear that the user can select multiple options.
  • Place hint text under the form label.
  • Use a single checkbox where a user needs to indicate agreement (for example to terms and conditions).
  • Make checkboxes easy to tap, with a target height of at least 44 pixels.
  • Checkboxes must ALWAYS be square.
Graphic of a checkbox box

Research insights and sensible thinking

Accessibility considerations for checkboxes

  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3
  • Checkbox outline and checkmark needs a 3:1 contrast ratio against the background. WCAG 1.4.11
  • For an accessible label, group checkboxes together in a field set and legend that describes them.
  • Checking a box must not cause anything surprising to happen like submitting a form, significantly changing the content on the page, or moving the keyboard focus. WCAG 3.2.2

Checkboxes in the wild

The component gallery: Checkboxes

Back to top

Notifications

Notifications alert users to important information or changes on a page. Helpful ones attracts the user's attention without interrupting the flow of the task. They often appear at the top of a page following a submit action.

My guidelines

  • Notifications typically come in 4 flavours; Information, Warning, Success or Error.
  • Users have a mental model for alert colours. Stick with Information=Blue, Warning=Orange, Positive=Green and Error=Red.
  • Provide an additional indicator to colour, like an icon.
  • Use notifications purposefully, keep text short and simple.
Graphic of 4 notitications - warning, success, info and error

Research insights and sensible thinking

Accessibility considerations for notifications

  • Text needs a 4.5:1 contrast ratio against the background. Check coloured text on a tinted background. WCAG 1.4.3
  • Icon needs a 3:1 contrast ratio against the background. WCAG 1.4.11
  • Consider users with colour vision deficiency. Test your alerts on a colour blind person, or use a free colour blind simulator like Color Oracle. See an example in my accessibility case study
  • Don't rely on colour alone to convey your message. Provide an additional indicator to colour, like an icon.WCAG 1.4.1

Notifications in the wild

The component gallery: Notifications

Back to top

Error messages

Display an error message when there is a form validation error on submit. Explain what went wrong and how the user can fix it.

My guidelines

  • Display error text above the input field.
  • Use a red icon, an error message and a red border to highlight the field that needs attention.
  • Use positive, conversational language in active voice. Don't say please or apologise. Just get to the point.
  • Inline validation can be useful for password criteria affirmation, otherwise avoid it.
Graphic showing an example error message

Research insights and sensible thinking

Accessibility considerations for error messages

  • Error Identification WCAG 3.3.1
  • Provide a text description when user input falls outside the required format or values W3C Techniques for WCAG 2.1
  • Text needs a 4.5:1 contrast ratio against the background. Check your red text. WCAG 1.4.3
  • Icon needs a 3:1 contrast ratio against the background. WCAG 1.4.11
  • Consider users with colour vision deficiency. Test your error messages on a colour blind person, or using a free colour blind simulator like Color Oracle.
  • Don't rely on colour alone to convey your message. Provide an additional indicator to colour, like an icon. WCAG 1.4.1

Error messages in the wild

Back to top

Date input

Quickly enter a meaningful date or a date from a document.

My guidelines

  • Three input fields are the easiest way for users to enter most dates.
  • Clearly label input boxes to remove any confusion over date format.
  • Don't automatically tab users between the fields.
  • Be sympathetic to user entry, for example allow 01 and 1.
Graphic showing an example date input field with 3 boxes

Research insights and sensible thinking

Accessibility considerations for date input

  • For an accessible label, group the three fields together in a fieldset and legend that describes them. See Making labels and legends headings from Government Digital Service.
  • When any user interface component receives focus, it does not initiate a change of context. WCAG 3.2.1
  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3
  • Input box needs a 3:1 contrast ratio against the background. WCAG 1.4.11

Date input in the wild

The component gallery: Date input

Back to top

Select

Select boxes allow users to select one item from a list. I'm not a fan! They don't show all the choices upfront. They can be difficult to navigate with a keyboard or a touch device. I've seen users confused by them in testing.

My guidelines

  • Use select boxes as a last resort. Can you ask the question differently? Use a stepper, a radio group, or a selector instead?
  • If you have to use a select box then default to the device or browser default.
Graphic showing an example select dropdown

Research insights and sensible thinking

Accessibility considerations for select boxes

  • Text needs a 4.5:1 contrast ratio against the background. WCAG 1.4.3
  • Select box outline needs a 3:1 contrast ratio against the background. WCAG 1.4.11
  • Selecting an option must not cause anything surprising to happen like submitting a form, significantly changing the content on the page, or moving the keyboard focus. WCAG 3.2.2

Select in the wild

The component gallery: Select

Back to top

👋 These are my opinions based on my experience, research and testing to date. Yours might differ based on your goals, target audience, location and product. Test whenever you can and use your metrics to inform choices. I'm always learning so if you discover a better way of doing something I'd love to hear about it.

Headshot of Geri Reid, a white woman with long dark hair, wearing a blue and white striped top, looking off to the side

About me

I've designed digital products for the past two decades.

As design and accessibility lead on NewsKit design system, I helped some of the UK's largest media and broadcast brands to design at scale. I was design lead on the Constellation design system at Lloyds Banking Group and set up design system foundations at Checkout.com and BPP. Way back, I designed digital products at UBS and Bank of America.

Over time, my design roles have become more strategic: planning, training and writing technical specs and docs. My work on systems has also made me a keen accessibility advocate. Through care and attention, I've learned how a design system can provide a solid foundation for product accessibility.