Skip to main content

Input

Description​

Inputs allow a user to type or select a value to input to a system. We use inputs when we need to collect text, numeric data, or a combination of both in the form of text input, text area, numeric input, and filter input. Variations and rules for specific input types are described below.

When implementing inputs, always declare the appropriate HTML input type to ensure that mobile browsers invoke the correct mobile keyboard.

Sizes​

Input sizes are large, medium (default), and small.

Input width is determined by its content, layout requirements, and minimum left/right padding. Designers are free to adjust input widths wider than the minimum, but full-width inputs should be reserved for narrow layouts such as mobile screens or narrow slideouts.

Usage​

Scale Alignment​

Always match input size with button size: i.e., medium inputs with medium buttons; small inputs with small buttons.

By default, we use medium inputs in most cases. In dense layouts where vertical space is at a premium, small inputs may be used on large screens. Small inputs are never used on mobile screens. Large inputs may be an appropriate option for certain applications intended for tablet use in the field.

Coming soon: example of scale alignment

Labels​

Include clear and persistent labels with all inputs.

Labels are written in sentence case, without punctuation.

Labels are top aligned (default), placed left-aligned on top of the input field and placed right-aligned on the left of the input field, or hidden. The default is best for most scenarios. Only use right aligned labels when it is necessary to save vertical space.

Hidden labels should be used with caution and only when there are very few fields (e.g., a sign in form), or where the required input is very well understood by the user (e.g., the user’s street address). Hidden labels must still be represented in the code for accessibility purposes.

Required vs Optional​

When designing forms, aim to include only required fields. Avoid optional fields unless designing a search/filter scenario where all fields may be optional.

Coming soon: example of required vs optional fields

When a mix of required and optional fields cannot be avoided, mark fields as “optional” or “required” next to the input label. In this scenario, we only mark the exception –for example, in a form of ten fields: when nine fields are optional, but one is required, only annotate the one required field.

Do not mark required form fields with an asterisk (*). Optionally, designers can include a text instruction, “All fields are required.” at the top of the form. Give required fields priority in the field order when possible.

Coming soon: Example including do/do not

Validation​

When a specific input is required, validation should take place as soon as technically possible in the user's experience. This begins when a user is entering information in a field (e.g., a matching password field), then when a field loses focus (e.g., an email field), then on submit (e.g., username taken).

Coming soon: Example including do/do not for validation

Decorations​

Some input types have the option to display a left decorative icon, a prefix (e.g., a dollar sign), or a suffix (e.g., a percentage sign). These display rules apply:

  • Do display an icon that is decorative or explanatory only (e.g., an envelope icon in an email field).

  • Do not display a decorative icon and a prefix together.

Coming soon: Example of decorative

Helper Text​

Some input types can optionally display helper text below the input. Help text provides guidance or instructions to people filling out a form field. It can also be used to clarify how the information will be used.

Helper text should be very brief (single line if possible) and explanatory or illustrate a desired format. Avoid repeating the field label. If the field label provides sufficient context for completing the action, then you likely don’t need to add help text.

When a field fails validation, helper text is replaced by a validation message.

Coming soon: Example replaced validation message

A custom help message should be provided for password entry since its requirements are usually too complex to describe in one line.

For other types of fields, the error text would contain information about why it failed validation. In other words, if there is important information in the helper message, this should display in the error message.

Formatting User Input​

Inputs requiring a specific number format should allow users to type the input as they wish without triggering a format error. The field should auto-format the displayed entry as the user types and submit in the format required by the system. This can be done by ignoring all non-numeric characters entered (parentheses, dashes, dots, etc).