E5.02.2destinations versus actionsdesign

Tabs must be peer destinations, not actions

Aliases: destination-based navigation · tab as place

What it is

Each item on a bottom tab bar should be a destination someone can remain in, not an action that fires once and disappears. Home, Search, Messages, and Profile are places one can revisit. Publish, Scan, and Create start a procedure. Put an action on the bar and selected state loses its meaning: after Publish, which item should stay selected? People can no longer read the bar as “which station am I in”.

Why it happens

Selected state on a tab bar is a location signal: the highlighted item says which of several peer spaces you occupy. Destinations satisfy that semantics — switch to Messages and you sit in the messages stack; leave and return and it is still the same place. Actions do not: they open a camera, an editor, or a one-shot flow, then either dump you back where you were or into a page that never appeared on the bar. If the action item takes a selected state, the highlight lies. If it does not, the rule “exactly one item is selected” breaks, and people must extra-decide whether this item goes somewhere or pulls a trigger.

Mixing also warps architecture. Actions get a raised centre button whose visual weight beats the real destinations, forcing use while occupying a slot that should have been a peer space. Fewer places remain visible on the bar, even though that action could have lived on the top bar or in content. The bar has been conscripted as a toolbar, and it is no longer a map.

Where it stops holding

A few products make Create a centre item that immediately covers the screen, and people have learned it is not a station. That usage depends on a visual exception (raised, not isomorphic with its neighbours), not on tab semantics, and does not generalise to “actions may be tabs”. Search is a destination if it is a space one can stay in and restore last query; it is an action if it only pops a keyboard and dismisses, and should not take a tab slot. A desktop sidebar “New” at the foot of a list is toolbar mode; do not blend it with the selected-state model of a bottom tab bar.

Applying it

  • For every candidate, ask whether coming back later still leaves the person in the same space. If yes, it is a destination; if not, it is an action — put it in content, the top bar, or a floating button.
  • Keep exactly one item selected. If a tap opens a modal flow, restore the previously selected destination when the flow ends; do not light the action item.
  • Give an emphasised create action a control that is not isomorphic with tabs, so it does not compete for selected state.
  • How to check: round-trip every tab and ask “which station are you in”. An item that cannot be named as a place, or is answered as “I just posted”, is an action on a destination bar. Then inspect screenshots: there should always be exactly one highlighted item.

Related

  • Within the group: E5.02.1 Tab count is capped by width and legibility · E5.02.3 Switching tabs must preserve each tab’s place
  • Adjacent: E5.11 Tabs · E5.16 Shortcuts and Pinned Items
  • Search terms: destinations versus actions · tab bar semantics · selected state

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/E5.02.2