UX Patterns Guide

Foundation · lesson 2 of 21 · Navigation And Wayfinding

Header / top app bar

Underlying principle: Navigation exposes the site's structure at the moment a person needs to move. A useful route has a recognizable label, a predictable destination, and an orientation cue after arrival.

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.

Start with the decision

Does this fit your task?

A screen needs a current title plus back, close, menu, search, save, share, edit, or overflow actions.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

Navigation exposes the site's structure at the moment a person needs to move. A useful route has a recognizable label, a predictable destination, and an orientation cue after arrival.

01 / Recognize the need

What the person is doing

Users need a small set of actions that act on the current view or selected content.

02 / Design the response

What the interface must communicate

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.

Default state with current view title and correct leading affordance.

03 / Judge the outcome

What to look for

Does the title in the bar exactly match the current screen or selected mode?

The title in the bar must match the rendered content or current route.

Practice this pattern: Sketch header / top app bar for this situation: A screen needs a current title plus back, close, menu, search, save, share, edit, or overflow actions. Include this state: Default state with current view title and correct leading affordance. Review your sketch with this question: Does the title in the bar exactly match the current screen or selected mode?

Study the Navigation And Wayfinding family →Read the underlying principle →
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 page is a public document where a simple site header and page heading are enough.
  • A strict linear transaction would be safer with a simpler heading, progress indicator, and explicit continue/back controls.

Problem it prevents

Users need a small set of actions that act on the current view or selected content.

Test the behavior

Try strong and weak versions of the interaction

Open the working example, try its controls, and compare the behavior against the decision guidance.

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 Header / top app bar in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Users need a small set of actions that act on the current view or selected content.

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.

Failure to inspect

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.
  • On scroll, a large title collapses to a compact title while the back affordance and critical action remain reachable.
  • Users switch from Details to Files and the title and primary action change together from Share to Upload.
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.
  • 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.

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.
  • Keep focus order from leading navigation, title-adjacent controls, visible actions, overflow, then content predictable.

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?
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

Source trail checked:

Saved items