Input Fields

Input fields allow the user to input freeform or structured text. One or multiple input fields are usually followed by a “Submit”, “Save” (or similar) action button.

Guidelines

Input fields give users a way to enter any kind of text into a field. Input fields can be programmed to have conditional limitations. When necessary, they can include hint text to let the user know what to enter, or to give them an example. Generally speaking, input fields should include a top or left label.

Types

Input fields come with 2 label positioning options.

Left Label
Top Label

States

Input fields come in the following states:

Enabled
Disabled
Error
No Hint Text

Dimensions

Input fields come in following 3 sizes:

24px
24px Input Field blueprint
36px
36px Input Field blueprint
44px
44px Input Field blueprint

Conditionals

Input fields can be programmed by engineers on a case-by-case basis to limit what the user can enter. These can include character limits, can only accept certain types of characters (numericals, letters, special characters), can require validation, etc.

Phone Only
Credit Card Number
Error

Auto-Formatting vs Input Masks

Input fields can be programmed to be auto-formatted but cannot currently accept input masks.

Auto-Formatting
Input Fields DONT example

Guidance

Here are a few examples of how best to input fields.

DO

Use title case for Input Field labels.

DON'T

Avoid using sentence case for Input Field labels.

DON'T
Input Fields DONT example
Avoid using 2 or 3 columns for groups of input fields. Usability testing has shown that using 2 or more columns slows the speed of comprehension and obscures the path to completion.
DO
Input Fields DO example
Present all input fields in one column.
DON'T
Input Fields DONT example
Avoid using left label input fields when laying out multiple input fields in a group as it adversely affects visual alignment and user’s ability to quickly “connect” which labels belong to which input.
DO
Input Fields DO example
In almost all cases, use input fields with top labels.
DON'T
Input Fields DONT example
Avoid using title case for labels as sentence case is slightly easier (and faster) for reading than title case.
DO
Input Fields DO example
Use sentence case for all labels.

Spacing Guidelines

We suggest the following spacing guidelines for desktop and mobile use cases.

Spacing Guidelines Example
Use at least 8 px spacing between each input field.

Required Input Guidance

We suggest the following guidelines for indicating an input is either required or optional.

DO
Required Input DO Guidance
Use the Required notation only on inputs that are unique in that regard. In this case, there are 4 inputs and only one of them is optional. In order to reduce cognitive load, only use the Required notation on one of the inputs.
DON'T
Required Input DONT Guidance
Avoid using the Required notation on the majority of inputs. In this case, there are 4 inputs and only one of them is optional. It is easier for the user to understand that only one the fields is optional.
DO
Required Input DO Guidance
When faced with an equal number of fields where half of the inputs are required and the other half are not required, use the Required notation on the fields that are required.
DON'T
Required Input DONT Guidance
Avoid using the Required notation on every input in a group.
DO
Required Input DO Guidance
Use Accent color to indicate required inputs if you feel the Required Notation needs extra visibility.
DON'T
Required Input DONT Guidance
Avoid using background fills to further distinguish required inputs.
DO
Input Fields DO example
In cases where there is only one required input in a page container, there is no reason to use the Required notation as it’s status as a required input can be addressed with the primary action.
DON'T
Input Fields DO example
In cases where there is only one required input in a page container, there is no reason to use the Required notation as it’s status as a required input can be addressed with the primary action.