Forms allow users to enter data that is used by the application, or to configure options. Designing forms well requires decisions about its structure and sequence, as well as its interface elements, field labels and offered help and feedback.

Form details

Forms example
Form labels:
Use sentence case only. Default alignment is right aligned. Long labels should wrap and should not be truncated.
Required field labels:
Mark required fields with a *. If all fields in the form are mandatory, don't provide any indication.
Form fields:
The length of the field should communicate the intended length of content. Available lengths are 75px, 165px, 250px, 350px, 500px and 100% width. These lengths also apply for other form controls of a similar shape, like drop-down menus and text boxes.
Disabled fields:
Only show disabled fields if users need to know that the control might be available to them in other scenarios.
Auto focus the first field by default. Users should then be able to tab through elements in the form in a logical sequence. This maintains Section 508 accessibility compliance .

Form layout

Forms example
Form title:
Describes the form as a whole. If the form is the main item on a page, use an h2 tag, otherwise use h3 and adjust the rest of the page hierarchy accordingly. This can be followed by a short paragraph of text to introduce the form.
Form group headline:
Describes a group of controls and fields within a form that relate to each other and where users benefit from concentrating on them as a whole. Usually h3. This can be followed by a short paragraph of text to explain the group.
End of form line:
If the form has more than one form group, a line is necessary so users understand the form actions apply to the form as a whole.
Form buttons:
A form usually has a primary button for the main action, and a link button to cancel. The primary button is left aligned along with the left side of the form fields. If more actions are needed, put the primary button first, then any standard buttons, then the link button. The only exception is a multi-step form where the 'Back' standard button sits at the very left, while the rest of the buttons are aligned as usual.
Field order:
Group related fields and controls together. If one field impacts another field, always place it before the field it impacts.

Label alignment

Standard label alignment is right aligned.
Choices within choices:
The main choice uses a left aligned label. Choices nested within this choice use top aligned labels.
Short form:
For very short forms, use top aligned labels. Do not use top alignment on a short form if it is part of a multi-step form and other pages use left aligned labels.

Form help

Forms must be easy to fill out. Target users often need help to clarify what information is required from them. Provide help where needed but bear in mind that too much help can make the form look busy and difficult.

Forms example
Placeholder text:
Informs users what they need to do to interact with the field (e.g. 'Start typing to see names'), or shows an example of a typical entry (for example, 'e.g. My first project'). Examples must start with 'e.g.' Only supply placeholder text where clarification is required, do not overuse it.
Field rules information and tooltip:
On focus of the field, or on click of the 'i', provide information within an inline dialog that explains the rules and restrictions of a form field (e.g. 'Passwords must be between 8-20 characters long'). Keep this text as short as possible. If rules are sophisticated, provide a link to more information within the inline dialog and open the link in a new browser tab.
Help indicator and tooltip:
The 'i' shows that there is information available that explains the meaning of a field in more detail. It triggers an inline dialog that can have a headline, paragraph text and actions. Do not overuse the help indicator. The 'i' icon should appear to the right of the field. If information is only relevant when entering data, omit the 'i', and trigger the inline dialog on field focus. If there is too much information to fit in the help indicator, a link should be provided to an external page (in a new browser tab) that provides additional information.

Error and success – system feedback

Forms example
Field error:
When a form or field submission fails, all fields responsible for the problem are shown with a red outline and an exclamation mark icon.
Field error message:
The error icon behaviour is the same as the help icon (displayed on focus and on click of the icon). Error messages should be relevant to the user and human in their writing style. Do not stack error messages, but rather think about what users need to do to resolve the problem. In case the error is shown for a field that would otherwise have help text, write your message in a way that both explains the field and the error. If the error requires explanation in detail, a link should be provided to an external page (in a new browser tab). If the error explanation includes dynamic content, such as diagnostic information, it should be opened in a modal dialog.
Field success indicator:
Where inline validation happens immediately, a correctly filled out field shows a success icon.

Form validation timing:

– Real-time validation: By default, fields will validate after the user loses focus and the field value has changed. If necessary, the field then shows a progress indicator and comes back either with a field success or error state. If the field validates successfully, an icon should only be displayed if it's beneficial for the user to know that the field value has validated (e.g. a unique username was entered).

– Full page validation: Where real-time validation is not possible or doesn't make sense, all fields are validated at the same time on page submission. During page validation, the primary action label turns into a progress indicator. If fields have caused problems, all problematic fields are shown as field errors. The form will automatically focus on the first problematic field. If validation requires a full page reload, ensure that the first invalid field is focused when the page is loaded.

Complete form success and error: If necessary for user understanding, show a confirmation message at the top of the form (if the screen doesn't change) or the next page (if form submission moves users to another page) after successfully submitting it. Where it can't be identified exactly which fields have led to the form submission to fail, use an alert message. Make sure the message text helps users as much as possible to rectify the problem.

Forms example

Forms example

An effective way of preventing users from sending off an incomplete form is to disable the buttons at the end of the form until all mandatory fields have been filled out. Be aware though that this means users will not see error messages that might help them rectify problems.

Choices in forms

Many forms ask users to select one or many items of a finite set of options, and can be nested.

Single choice: Radio buttons vs. dropdown menus

When users need to choose one item out of a list of options. There is no hard and fast rule of when to use radio buttons and when to use dropdown menus, but see general guidelines below:

Radio buttons: Use radio buttons when the number of options is small, and when options benefit from a longer label to explain the differences of each option. Radio buttons are always listed vertically.

Dropdown menus: Use dropdown menus when the number of options is large, or has the potential to become large due to user activity. Options should be of the same nature (e.g. a list of branches, or a list of people). Typeaheads are also in this category.

Forms example

Multiple choice: Check boxes

When users might choose more than one option. Check boxes are always listed vertically.

Designing long forms

When users access a form, it can be daunting to immediately see a large number of fields that need to be filled out. The threshold for when a form is considered 'too long' depends on the audience and the application context. There are various techniques of lessening the impact of long forms.

Multi-step forms

The focused task pattern shows a multi-step approach that can be used to spread form fields across more than one screen. Make sure each screen shows fields that logically belong together, and that move users forward through the larger form step by step. This pattern is also good for saving progress through a form along the way. However, make sure users know what has and has not been executed for them along the way.

Progressive disclosure

A form can reveal more content as users go through it and use fields and controls. This technique can be used when it is not necessary to see all controls unless users have made specific decisions (e.g. unless they checked a particular check box), or when a particular decision has to be made first before it would make sense to move forward in the form.