| Introduction | Notifications | Grids | Colours | Typography | Image Sizes | Padding and Spacing | Modals | Icons | Social Norms | Dividers
| Tables | Package Selector | Timelines | Progress Indicator | CTAs and Buttons | Forms | Tooltips | Accordions | Loaders |
We use a form to collect a set of information that we need from the user.
Short
Forms should be short and only ask necessary questions.
Scannable
Forms should be easy to scan.
Clear
Forms should make clear what information is required and what’s optional.
Input fields
Avoid optional fields
Try to avoid optional fields. But when we do use them, we add ‘(optional)’ after the label text, rather than use * to indicate required fields.
Clear distinction between primary and secondary buttons
It’s important that primary and secondary buttons look different. Lack of visual distinction between the actions can confuse the user and lead to them not completing or submitting the form.
Button placement
Left align the primary button below the text field. Don’t put the ‘Cancel’ or ‘Back’ button right below a field – users could click it by accident.
We use forms for:
Vertically group related labels and fields
If a form has horizontally adjacent fields, the user has to scan in a Z pattern, slowing them down and muddying the path to completion. But if a form is in a single column, the path to completion is a straight line down the page.
Spacing/grouping
When a form has different sections or topics, organise the content into logical groups to aid scanning and completion. Use a standard divider to separate content (see component library).
How it behaves
Action buttons
Make it clear when the form is being processed
Disable all buttons and clearly communicate when the form is being processed to avoid duplicate submissions.
Validation
Inline validation
If something’s not right, we should let the user know as soon as they’ve entered the data and clicked outside the field. This means they can see and correct any errors faster, without having to wait until they’ve clicked the ‘Submit’ button.
Validate after field is filled in
Validation cannot verify before user finished typing an answer.Forms that validate during data entry punish the user as soon as they start entering data.
How it behaves
Action buttons
Make it clear when the form is being processed
Disable all buttons and clearly communicate when the form is being processed to avoid duplicate submissions.
Validation
Inline validation
If something’s not right, we should let the user know as soon as they’ve entered the data and clicked outside the field. This means they can see and correct any errors faster, without having to wait until they’ve clicked the ‘Submit’ button.
Validate after field is filled in
Validation cannot verify before user finished typing an answer.
Forms that validate during data entry punish the user as soon as they start entering data.
1.0.1
1.0.0