Forms let people enter data needed to use the platform.

Also known as:
InputsLabelsPlaceholdersValidationForm layout

AnchorNeed to know

  • Every form has a primary and secondary action.

To keep in mind


See individual component pages for label and input layout. We optimize for readability, scannability and time to form completion.

Our preferred layout is with individual form elements stacked vertically, grouped by context as necessary.


We require a single primary action to submit, with a secondary action to cancel and discard edits.

For accessibility reasons, you should allow users to press the primary action button at all times. Do not make the button inactive, even when required fields are empty. Instead, trigger client-side validation to highlight the empty fields.

Validation and feedback

Where possible, use client-side validation to present the user with feedback before submitting the form.

Validate on press of the submit button. Do not validate on field selection or 'blur' (clicking out of the field).

If errors are present, reveal all relevant error messages and focus the user on the first invalid field on the page. You may also want to show a negative confirmation modal, then allow the user to navigate to the first error (or cancel to do nothing).


All form elements must have a label associated with the input. There are reasons you might make it visible to sighted users or not, see individual component pages for details.

When to use and when not to use

When to use
  • Only prompt for user input necessary to a specific task or action.
  • Prompt for input as close in time as possible to when it's needed.
When not to use
  • Don't prompt the user for input if the desired information can be determined via the browser (e.g. locale) or from data elsewhere in the system (e.g. asking a signed in user for their username).

See also

External links