Skip to content

Field

A field wraps a button or input with a label, helper text, and error message. The control is the interactive shell — available as a button or an input — and the field adds the surrounding label and helper structure.

Ready to use

DesignDevelopAccessibility

The Field is a fundamental UI element that allows users to enter, edit, and interact with single-line text data. It is the primary vehicle for data collection in forms and search interfaces, and is fully responsive across all viewports.

Anatomy

Section titled “Anatomy”
Helper text for the input field.
  1. Field
  2. Label
  3. Input
  4. Helper text
  5. Helper icon

When to use it

Section titled “When to use it”

Use the field when:

  • You need to collect short-form data (Name, Email, Password).
  • The expected input is a single line of text.

Avoid the field when:

  • The user needs long-form text — use a Textarea instead.
  • The input is a choice from limited pre-defined options — use a Dropdown, Radio Group, or Checkbox.
  • The input is a date or number — use specialised inputs that can leverage native mobile keyboards and validation.

Properties

Section titled “Properties”

State

Rested, Active, Hover, Focused, Disabled, Error, and Success. The focus state shows a 2 px outline; error pairs a coloured border with helper text and an icon so the message reads without colour alone.

Filled

Tracks whether the field carries a value. When filled, the label sits above the input as a compact eyebrow; when empty, the larger label sits inside the field as the placeholder hint.

Required

A boolean that surfaces the required marker beside the label. Keep the visible cue consistent with the form’s overall pattern for required fields.

Helper text

Optional one-line text beneath the input, used to communicate format hints or examples. Replace it with the error or success message when validation runs.

Helper icon

The small info icon paired with the helper text. Decorative — it reinforces the helper message and swaps to the matching error or success glyph when validation runs.

Optional icon

A leading icon slot, used sparingly to clarify intent (a magnifying glass for search, a lock for password). Default off — only enable it when the icon adds meaning.

Platform considerations

Section titled “Platform considerations”

Desktop

The field stretches to fit its column and respects keyboard focus management. Width should match the expected content length so the input doesn’t feel arbitrary.

Tablet

Same layout as desktop. Touch and pointer mix here — make sure the helper text and label remain readable when the on-screen keyboard pushes the form upward.

Mobile

The label persists above the input even when the keyboard opens. Use the right inputmode and autocomplete so mobile keyboards surface the right glyphs.

Best practices

Section titled “Best practices”

Consistency in input fields reduces cognitive load — every input must have a visible label and a clear focus indicator.

Do

Provide a clear, concise label above the input, surface format hint examples in the helper text, group related inputs logically inside form sections, and lean on native HTML elements so focus order and accessibility come for free.

Don't

Don’t hide the label while the user is typing, don’t trigger error states prematurely (wait for blur), and don’t rely on colour alone for error or success — always include an icon or helper text.

Content guidelines

Section titled “Content guidelines”

The label should name exactly the data you want — “Email address” beats “Email”, “Mobile number” beats “Phone”. Use the helper text to show the expected format with a real example so the user can match the pattern as they type. Error messages should name what went wrong and how to fix it (“Pick a number between 1 and 99”) instead of restating the field. Width should mirror the expected content length so a postcode field doesn’t sprawl like a long-name field.