UX Patterns Guide
UI + UX Navigation And Wayfinding established

Header / top app bar

Place a consistent top bar above the content that names the current view, gives the correct leading navigation affordance, exposes the highest-priority current-view actions, and moves secondary commands into an accessible overflow.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A screen needs a current title plus back, close, menu, search, save, share, edit, or overflow actions.
  • The product has deep or hierarchical views where users need local orientation inside the app shell.
  • Selection, search, or edit mode changes the relevant command set for the current content.

Avoid when

  • The interface only needs top-level destination switching and no current-view actions.
  • The page is a public document where a simple site header and page heading are enough.
  • The command set is too large to fit without prioritization; use menus, command palette, side panels, or page-level controls.
  • A strict linear transaction would be safer with a simpler heading, progress indicator, and explicit continue/back controls.

Problem it prevents

Users need to know which screen or view they are in and need fast access to the few navigation and action controls that apply to that current view.

Pattern anatomy

What a strong implementation has to make clear

User need

The product has deep screens where brand-level navigation alone does not explain the current view.

Pattern promise

Place a consistent top bar above the content that names the current view, gives the correct leading navigation affordance, exposes the highest-priority current-view actions, and moves secondary commands into an accessible overflow.

Required state

Default state with current view title and correct leading affordance.

Recovery path

Header title and content heading drift apart.

Access contract

Use semantic header, banner, navigation, and button roles only where their landmarks match the page structure.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A project detail screen shows Back, Project Apollo, Search, Share, and a More menu for secondary commands.
  • Selecting rows changes the bar to 3 selected with Archive, Move, and Clear selection actions.
  • Users switch from Details to Files and the title and primary action change together from Share to Upload.
  • Opening More reveals secondary view commands without hiding the current title or back affordance.
Weak implementation

Vague, hidden, hard to recover from

  • A header shows the app brand, five section links, account settings, export, delete, help, and sign out in one row.
  • The title says Reports while the content is Billing and the primary action still exports the previous screen.
  • The same Save icon appears in the header on screens where it saves, exports, or opens settings.
  • A scroll-collapsing header hides the back control and leaves users trapped deep in a hierarchy.
UI guidance
  • Render a top surface that clearly identifies the current view, provides one leading navigation affordance when needed, exposes a small number of view-level actions, and groups secondary actions behind a labeled overflow control.
  • Keep title, leading control, primary action, overflow, and scroll behavior stable enough that users can predict what the bar controls on every screen.
UX guidance
  • Use the header/top app bar to orient users inside the current view and make the most important safe commands reachable without confusing them with global destinations.
  • When selection, search, or editing changes the command set, switch to an explicit contextual bar and provide a clear way back to the normal title/actions.
Implementation contract

What the implementation must handle

States

  • Default state with current view title and correct leading affordance.
  • Primary action state with one to three visible current-view commands.
  • Overflow open state with secondary commands grouped and keyboard reachable.
  • Contextual selection or edit state with changed title and changed command set.

Interaction

  • The title in the bar must match the rendered content or current route.
  • The leading affordance must have one predictable meaning within the current navigation level.
  • Visible actions must operate on the current view or current selection, not a previous screen.
  • Overflow opens a menu of secondary commands, returns focus to its trigger when closed, and does not hide critical recovery.

Accessibility

  • Use semantic header, banner, navigation, and button roles only where their landmarks match the page structure.
  • Give icon-only actions accessible names and make visible labels available for ambiguous commands.
  • Expose expanded state for overflow menus and ensure menu items are keyboard reachable.
  • Do not rely on color alone to signal contextual mode, selection count, or disabled actions.

Review

  • Does the title in the bar exactly match the current screen or selected mode?
  • Which visible actions are truly frequent and specific to this view?
  • Can users predict what the leading icon will do before activating it?
  • What happens to title and actions when content scrolls, selection mode starts, or the viewport narrows?
Interactive lab

Inspect the states before you copy the pattern

Inspect current-view actions

Switch views, open overflow, enter selection mode, and check whether the title and actions stay scoped to the current view.

Header / top app bar
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Default state with current view title and correct leading affordance.

Keyboard / Access

Tab reaches the leading navigation control, visible actions, overflow trigger, overflow items, and then content in a predictable order.

Avoid Generating

Using the top app bar as a dumping ground for every global destination and account utility.
Evidence trail

Source-backed claims behind this guidance

Material Design: Top app bar

Material Design - checked

Material top app bar guidance defines title, navigation, action icons, overflow, scrolling, and contextual variants.

Android Developers: App bars

Google Android Developers - checked

Android app bar guidance documents top app bars as containers for title, navigation items, and core action items.

Carbon Global Header pattern

IBM Carbon Design System - checked

Carbon UI shell header style guidance documents header structure, action states, sticky behavior, and responsive collapse.

Full agent/debug reference

Problem Context

  • The product has deep screens where brand-level navigation alone does not explain the current view.
  • Users need a small set of actions that act on the current view or selected content.
  • The same app shell may need normal, search, selection, edit, and narrow-width header states.

Selection Rules

  • Choose a header/top app bar when each screen needs a current title plus view-level actions such as search, share, edit, save, or overflow.
  • Use a leading back, close, menu, or drawer button only when that affordance matches the current navigation structure and will behave consistently.
  • Limit visible actions to the most frequent, safe, and screen-specific commands; move lower-priority commands to overflow.
  • Use a contextual top app bar when selection or editing changes the available command set for the current content.
  • Keep global section links, account utilities, and site-wide navigation visually separate unless the design system explicitly defines a combined shell header.
  • Use tabs, segmented controls, side navigation, or global navigation instead when the main job is switching destinations or sibling content rather than acting on the current view.

Required States

  • Default state with current view title and correct leading affordance.
  • Primary action state with one to three visible current-view commands.
  • Overflow open state with secondary commands grouped and keyboard reachable.
  • Contextual selection or edit state with changed title and changed command set.
  • Narrow viewport state where actions collapse without losing critical navigation.
  • Scrolled, sticky, or collapsed state that preserves orientation and recovery.

Interaction Contract

  • The title in the bar must match the rendered content or current route.
  • The leading affordance must have one predictable meaning within the current navigation level.
  • Visible actions must operate on the current view or current selection, not a previous screen.
  • Overflow opens a menu of secondary commands, returns focus to its trigger when closed, and does not hide critical recovery.
  • Entering contextual mode changes the bar label and actions; leaving contextual mode restores the previous title and actions.
  • If the bar sticks, collapses, or scrolls away, users still have an obvious way to identify the view and recover navigation.

Implementation Checklist

  • Derive the title and leading affordance from route or navigation state rather than static header copy.
  • Inventory view-level commands and rank them before deciding which actions are visible versus overflowed.
  • Give icon-only actions accessible names and visible labels where the meaning is not universally obvious.
  • Implement overflow as a keyboard-accessible menu with Escape dismissal and focus return.
  • Define responsive rules for which actions collapse, which remain visible, and how contextual mode behaves.
  • Test route changes, scroll collapse, selection mode, and narrow widths for title/action synchronization.
  • Keep account, help, product switcher, and global destinations outside the current-view action group.

Common Generated-UI Mistakes

  • Using the top app bar as a dumping ground for every global destination and account utility.
  • Showing stale titles or actions after route changes.
  • Putting destructive or rare commands as unlabeled visible icons.
  • Changing the meaning of the leading icon between back, menu, and close without clear context.
  • Hiding save, cancel, back, or recovery actions in overflow when they are essential to the current task.
  • Duplicating the same destinations in a global nav row, top app bar, and bottom navigation.

Critique Questions

  • Does the title in the bar exactly match the current screen or selected mode?
  • Which visible actions are truly frequent and specific to this view?
  • Can users predict what the leading icon will do before activating it?
  • What happens to title and actions when content scrolls, selection mode starts, or the viewport narrows?
  • Are global destinations and account utilities separated from current-view commands?
Accessibility
  • Use semantic header, banner, navigation, and button roles only where their landmarks match the page structure.
  • Give icon-only actions accessible names and make visible labels available for ambiguous commands.
  • Expose expanded state for overflow menus and ensure menu items are keyboard reachable.
  • Do not rely on color alone to signal contextual mode, selection count, or disabled actions.
  • Keep focus order from leading navigation, title-adjacent controls, visible actions, overflow, then content predictable.
Keyboard Behavior
  • Tab reaches the leading navigation control, visible actions, overflow trigger, overflow items, and then content in a predictable order.
  • Enter or Space activates buttons; Escape closes overflow or exits transient contextual UI when appropriate.
  • After closing overflow, focus returns to the overflow trigger.
  • After route navigation from the leading affordance, focus follows the app's page transition convention.
  • Selection mode controls must be reachable and the clear or cancel action must not require pointer input.
Variants
  • Small top app bar
  • Center-aligned top app bar
  • Medium or large top app bar
  • Sticky header
  • Collapsing header
  • Contextual action bar
  • Search header
  • Split header with global shell and local top app bar

Verification

Last verified: