UX Patterns Guide
UI + UX Selection And Choice standard

Segmented control

Present adjacent options as a single control with one active segment and immediate local effect.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • There are a few mutually exclusive modes.
  • The change affects nearby content immediately.

Avoid when

  • Options are full content sections needing tab semantics.
  • The set is long or labels cannot fit.
  • The choice is a submitted form answer that needs explanations or validation.
  • The control would trigger actions rather than changing a view, filter, sort, or mode.

Problem it prevents

Users need to switch between a small set of mutually exclusive modes, filters, or views in a compact area.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Segmented control in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The options alter a local view or setting rather than navigate to separate content sections.

Pattern promise

Present adjacent options as a single control with one active segment and immediate local effect.

Required state

Default selected segment.

Recovery path

Ambiguous icon-only segments.

Access contract

Expose selected or pressed state and the group name.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Two to four adjacent segments with a clear selected segment, visible focus ring, and readable labels that fit on one row.
  • The affected list, chart, or view sits immediately next to the control and visibly changes.
  • Selecting a segment changes a nearby local mode, filter, or view immediately.
  • Exactly one segment is active and the previous selection is automatically deselected.
Weak implementation

Vague, hidden, hard to recover from

  • Many cramped segments with truncated text.
  • Icon-only segments whose meaning changes by context or a group that wraps into multiple rows.
  • Using segments for unrelated destinations.
  • Changing distant content without indicating what changed or using a segment to execute an action.
UI guidance
  • Render a compact horizontal group with two to four adjacent segments, one selected state, visible focus, and stable sizing.
  • Keep labels concise, avoid mixed icon/text rhythm, and place the changed local content directly below or beside the control.
UX guidance
  • Help users switch a local mode, view, filter, sort, or presentation immediately without navigation or form submission.
  • Avoid using segments for unrelated pages, hidden content sections, destructive actions, or choices that need long explanation.
Implementation contract

What the implementation must handle

States

  • Default selected segment.
  • Unselected segment state.
  • Focused segment state.
  • Changed local view state.

Interaction

  • Selecting a segment updates the local mode or filter immediately.
  • Exactly one segment is active unless the control is explicitly multi-select.
  • The active segment is visually and programmatically clear.
  • The affected content sits adjacent to the control and updates without page navigation.

Accessibility

  • Expose selected or pressed state and the group name.
  • Do not rely on position or color alone.
  • Ensure each segment's accessible name matches its visible label or icon meaning.
  • Tab reaches the control.

Review

  • Is this a compact local mode choice rather than page structure?
  • Can users see the affected content change immediately after selecting a segment?
Evidence trail

Source-backed claims behind this guidance

VA Design System Button - Segmented

VA.gov Design System - checked

VA documents segmented buttons as 2-4 mutually exclusive filters or view switches for one data set with one option always active.

Android Developers Segmented Button

Android Developers - checked

Android documents single-choice and multi-choice segmented button rows, selected state tracking, and a limit for complex or larger sets.

Fluent 2 iOS Segmented Control

Microsoft Fluent 2 - checked

Fluent iOS documents one selected option in a single context, concise labels, no page navigation, and no wrapping.

Full agent/debug reference

Problem Context

  • The options alter a local view or setting rather than navigate to separate content sections.
  • The choice set is short and benefits from persistent visibility.
  • The affected data or view is close enough that users can immediately understand what changed.

Selection Rules

  • Choose segmented controls for two to four closely related local modes, filters, sort orders, or view presentations.
  • Keep labels concise, preferably one word, because the group should not wrap or become a scrolling navigation strip.
  • Use tabs when each option exposes a distinct content panel or section.
  • Use radio groups when users need fuller option descriptions, validation, or a form answer instead of an immediate local view change.
  • Use pagination when the choices represent position in one ordered result set.

Required States

  • Default selected segment.
  • Unselected segment state.
  • Focused segment state.
  • Changed local view state.
  • Disabled or rejected overflow state when too many options are proposed.

Interaction Contract

  • Selecting a segment updates the local mode or filter immediately.
  • Exactly one segment is active unless the control is explicitly multi-select.
  • The active segment is visually and programmatically clear.
  • The affected content sits adjacent to the control and updates without page navigation.
  • Keyboard users can move between segments and select a segment without losing context.

Implementation Checklist

  • Name the group when the meaning is not obvious.
  • Expose selected or pressed state for each segment.
  • Keep the affected content adjacent.
  • Avoid wrapping segments unpredictably.
  • Reject or redesign sets that need more than four or five compact labels.
  • Avoid mixing icon-only and text segments unless the meaning remains obvious.

Common Generated-UI Mistakes

  • Using segments for unrelated page navigation.
  • Packing too many options into a tiny control.
  • Using icons without labels for ambiguous modes.
  • Using a segmented control to initiate actions such as add, edit, or delete.

Critique Questions

  • Is this a compact local mode choice rather than page structure?
  • Can users see the affected content change immediately after selecting a segment?
Accessibility
  • Expose selected or pressed state and the group name.
  • Do not rely on position or color alone.
  • Ensure each segment's accessible name matches its visible label or icon meaning.
Keyboard Behavior
  • Tab reaches the control.
  • Arrow keys or normal button tabbing should match the implementation semantics.
  • Enter or Space activates the focused segment.
  • Tab exits the compact group to the affected content or next control.
Variants
  • Two-segment toggle
  • View mode switcher
  • Filter segment

Verification

Source trail checked:

Saved items