skip to content

In a design system, when should a screen use tabs, a segmented control, or navigation links to switch between views?

level: juniorimportance: must knowfreq 52%

answer

  1. same page or new destination
  2. different content or same content
  3. panels versus modes versus pages
  4. does it have its own address
  5. a mobile bottom bar is navigation

basics

~20 s

Tabs switch between peer panels of different content within one page; a segmented control switches a mode or view of the same content; navigation links go to separate destinations with their own address and history.

solid answer

~40 s

The deciding question is **what changes when the user picks an option**. **Tabs** show one of several related panels of *different* content inside the same page — a library book's Details, Availability and Reviews. A **segmented control** is a compact single-choice control that changes a *mode* of the same content — showing search results as a list or a grid — and usually offers two to five options. **Navigation links** take the user to a *separate destination* — Catalog, Events, My account — which has its own address, can be bookmarked, opened in a new window and reached with the back control. Styling site navigation to look like tabs is fine; giving it the tabs keyboard and semantic model is not, because users then expect a panel on the same page.

go deeper

for a junior

Recall the one question that separates them: does an option change the destination, the content shown, or only how the same content is shown?

for a middle

Explain what each component promises: panels in one context for tabs, a mode of the same content for segmented controls, and addressable destinations for links.

for a senior

Spot the failures in real products: navigation given the tabs model, segmented controls hiding different content, tabs used where users need to compare.

for a principal

Name and document the in-page tabs component and the app-level navigation bar distinctly across web and mobile, so teams on each platform choose by behaviour.

## Three controls that look alike and mean different things In many interfaces a row of labelled options with an underline or highlighted pill can be any of three components. They look similar, but each makes a different promise about what happens when the user chooses an option. | Component | What an option changes | Typical count | Has its own address? | Example in a library catalog | |---|---|---|---|---| | **Tabs** | Which panel of *different* related content is shown | 2 to about 7 | Usually not required | A book page's Details, Availability, Reviews | | **Segmented control** | A *mode* or view of the *same* content | 2 to about 5 | No | Results shown as List or Grid | | **Navigation links** | Which *destination* the user is on | Any | Yes | Catalog, Events, My account | ## Tabs The WAI-ARIA Authoring Practices describe **tabs** as layered sections of content, called tab panels, that display one panel at a time; each panel has a tab that, when activated, displays it. The key properties: - The panels are **peers**: none is the main content and the others details. - The user stays **in one context** — the same book, the same account. - Only **one panel** is visible at a time, and the active tab is visibly marked. - The tab list behaves as **one composite widget** for the keyboard: the user moves between tabs with arrow keys, and the Tab key leaves the list. Tabs are a poor fit when users need to compare content across panels, since only one is visible at a time, or when there are so many sections that the tab list overflows. ## Segmented controls A **segmented control** is a compact, single-choice control whose options act on the same underlying content: a list or grid layout, a 'Books / E-books / Audiobooks' format filter, or a 'Day / Week / Month' range for a calendar of library events. It behaves like a single-choice group, and it: - keeps the content in place and changes its **presentation or filter**; - works best with **few, short options** that fit on one line; - is usually **not** given a panel for each option, because there is only one body of content. If each option would show entirely different content, the component is really tabs. ## Navigation links **Navigation links** move the user to another **destination**. That brings expectations that tabs do not carry: 1. The destination has its own **address** that can be bookmarked and shared. 2. The platform's **back** control returns to the previous destination. 3. The user can **open it in a new window** or tab of their own choosing where the platform allows it. 4. Each link is a normal stop in the keyboard sequence, rather than one stop for the whole group. A site header reading Catalog, Events, My account may be *styled* as a row of tabs, and that is a legitimate visual choice. What breaks users is giving it the **tabs model**: arrow-key movement, one tab stop, and an announcement that it is a tab list. A screen-reader user then expects a panel to appear on the same page and is surprised by a full page load. ## A cross-platform trap: the bottom tab bar Most native mobile platforms have a component called a **tab bar** or bottom navigation. Despite the name, it is **app-level navigation** between top-level destinations, each keeping its own history — conceptually closer to navigation links than to in-page tabs. A design system that serves web and mobile should name the in-page component and the navigation bar distinctly in its documentation so that teams do not borrow the wrong behaviour. ## Decision checklist - Does choosing an option change the **destination**? Use navigation links. - Does it change **which content** is shown, within one context? Use tabs. - Does it change **how the same content** is shown or filtered? Use a segmented control. - Do users need to **see two options at once**? None of these; lay the content out on one page.

  • Should tabs update the page's address so a panel can be linked to directly?
    It is often worth doing — a librarian sharing a link to a book's Availability panel expects it to open on that panel — but it does not turn tabs into navigation. The page is still one context with one panel visible, the keyboard model is still the tabs model, and switching panels usually should not flood the back history with an entry per tab.
  • What should a design system do when a tab list has more tabs than fit the width?
    First question whether tabs are right: many sections may be better as a page with headings or as navigation. If tabs stay, the spec should define one overflow behaviour — scrolling the tab list with visible affordances, or moving extra tabs into a 'More' menu — and keep the active tab visible. Wrapping tabs onto two rows is generally avoided because the rows' order becomes ambiguous.

A library building: tabs are the sections of one reference binder, a segmented control is switching the reading lamp between warm and bright on the same page, and navigation links are walking to a different room.

saying these in an interview costs you the question

  • Tabs and navigation links are the same component with different styling
  • A segmented control should hold a separate content panel per option
  • A mobile bottom tab bar follows the in-page tabs pattern
  • Site navigation needs the tabs keyboard model if it looks like tabs
  • Tabs are a good way to compare two sets of content side by side