Skip to content

Select Input

The select component allows users to choose one option from a list of predefined choices.

Anatomy

  1. Label: Indicates the purpose of the select component. It should clearly communicate what kind of choice is expected to be made.
  2. Description: Provides additional context/instructions about the choice
  3. Optional indicator: indicated that the choice is not mandatory
  4. Selection: displays the current selection that’s made by the user or the default from the system
  5. Input field: the interactive area where the user can click to see the available options
  6. Down arrow: a signifier that helps the user understand what to expect

Field Sizes

As layouts adapt to larger screens, flexible container dimensions are applied to form components for better readability. The default width is 4 grid columns (343px on mobile, expanding to 422px on desktop) for an optimized experience.

<Form>
<SelectInput label="Title">
<option value="Option 1">Option 1</option>
</SelectInput>
</Form>;
Open in StoryBook

In most cases, the select component follows the standard forms width, which adapts to the layout. However, when the string of character is short, it’s better to use a properly-sized select component.

Three characters

<Form>
<SelectInput label="Title" length={3}>
<option value="Option 1">Mrs</option>
<option value="Option 1">Mr</option>
<option value="Option 1">Mx</option>
</SelectInput>
</Form>;
Open in StoryBook

One character

<Form>
<SelectInput label="Initial" length={1}>
<option value="A">A</option>
<option value="B">B</option>
<option value="C">C</option>
</SelectInput>
</Form>;
Open in StoryBook

Placement in Layouts

Whether you’re designing a Z-pattern or an F-pattern layout, placing input components consistently improves readability and user flow.

Follow these two foundational rules:

  1. Always left-align components.

Align inputs and labels to the left to support natural reading flow and reduce cognitive load, especially in forms with multiple fields.

  1. Stack components vertically rather than placing them side by side.

Vertical stacking is easier to scan, reduces ambiguity about which label belongs to which input, and works better across screen sizes and accessibility contexts.

❌ Don't center components or place them side by side.
✅ Do left-align components and stack them vertically

The vertical order of input components is crucial for helping users navigate efficiently. A clear top-to-bottom layout aligns with natural reading patterns, ensuring a smoother experience. Avoid placing components horizontally, as it can disrupt the flow and lead to confusion.

Interactive States

Default

Description
<Form>
<SelectInput label="Title" description="Description">
<option value="Option 1">Option 1</option>
</SelectInput>
</Form>;
Open in StoryBook

Focus

Description
<Form>
<div className="o3-documentation-force-focus">
<SelectInput label="Title" description="Description">
<option value="Option 1">Option 1</option>
</SelectInput>
</div>
</Form>;
Open in StoryBook

Error

Description
<Form>
<SelectInput
label="Title"
description="Description"
feedback={{ type: "error", message: "There is an error" }}
>
<option value="Option 1">Option 1</option>
</SelectInput>
</Form>;
Open in StoryBook

Disabled

Description
<Form>
<SelectInput label="Title" description="Description" disabled>
<option value="Option 1">Option 1</option>
</SelectInput>
</Form>;
Open in StoryBook

Guidance on Disabled States

Select inputs support a disabled state, but it should be used sparingly and with care.

  • Only use disabled inputs when absolutely necessary, and always provide a clear explanation of why the field is disabled and how it can be enabled.
  • A common acceptable use case is for displaying read-only information that the user should see but not edit.
Description
<Form>
<SelectInput label="Title" description="Description" disabled>
<option value="Option 1">Option 1</option>
</SelectInput>
</Form>;
Open in StoryBook

When used without sufficient context, disabled inputs can:

  • Confuse users or make them feel stuck
  • Hide important information or functionality
  • Prevent error recovery or correction
  • Introduce accessibility issues, as screen readers may skip over disabled elements or fail to communicate their purpose

If a field must be temporarily unavailable, consider alternatives like making it read-only, providing inline messaging, or restructuring the flow to avoid exposing it unnecessarily.

Required and Optional Inputs

By default, all select components are considered required, unless explicitly marked as optional.

We intentionally do not display a “required” label or symbol. Instead, only optional fields are labeled, which simplifies the interface and reduces visual noise.

Why we don’t label required fields:

  • Reduces cognitive load by eliminating redundant information
  • Improves scannability in forms with multiple inputs
  • Avoids visual clutter, especially when form labels are stacked vertically

This approach helps users focus only on what they can skip, without having to mentally process which fields they must complete.

✅ Do mark optional input fields

Label content and Tone

Form field labels should be clear, concise, and easy to scan. We use sentence case for all labels and adopt a neutral, human tone to make forms more approachable and accessible.

Write labels with only the first word capitalized, unless the label includes a proper noun (like “UK” or “Google”).

This makes labels easier to read at a glance and better aligns with how people naturally process language in user interfaces.

❌ Don't use title case
✅ Do use sentence case