Choose responsive navigation adaptation when viewport width, device posture, orientation, pointer mode, safe areas, or destination count require navigation to move between bottom bar, rail, drawer, side panel, top overflow, or simplified header while preserving the same destination identities.
Choose responsive navigation adaptation when viewport width, device posture, orientation, pointer mode, safe areas, or destination count require navigation to move between bottom bar, rail, drawer, side panel, top overflow, or simplified header while preserving the same destination identities.
Practice the judgment: Imagine this situation: The mobile bottom bar, tablet rail, and desktop side nav use different labels for the same destination. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Responsive navigation adaptation | Global navigation | Bottom navigation | Navigation drawer | Side navigation | Header / top app bar |
|---|---|---|---|---|---|---|
| UI or UX | UI + UX - Navigation model that changes presentation across viewport, posture, and destination-count constraints | UI + UX - Persistent top-level navigation shell | UI + UX - Persistent mobile primary navigation | UI + UX - Dismissible slide-in navigation sheet | UI + UX - Persistent local hierarchy at the side of content | UI + UX - Current-view top bar with title, navigation affordance, actions, and overflow |
| UI guidance | Make adaptation rules visible in the interface: preserve current destination, expose overflow with a labelled control, keep safe-area and keyboard insets clear, and avoid duplicating the same primary destinations in competing navigation surfaces. | Render product or service identity, a compact set of top-level destination links, current-section state, separate utility controls, and responsive overflow behavior. | Render three to five bottom destinations with stable touch targets, labels or accessible names, reinforcing icons, selected state, optional badges, and safe-area spacing. | Render a navigation sheet that enters from the start edge or bottom, is opened by an explicit control, and presents grouped destination items with selected state. | Render a vertical navigation region beside the main content that exposes the current area's parent, child, and optional grandchild pages with a clear active indicator. | 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. |
| UX guidance | Use responsive navigation adaptation when users continue the same task across phone, tablet, desktop, split screen, rotation, or resized windows and need orientation to survive layout changes. | Help users move between major product or service areas while preserving orientation, local state, and confidence that they are in the right service. | Support rapid switching between top-level mobile sections while preserving each section's local navigation, scroll, filters, and drafts. | After a drawer item is chosen, close the drawer, update the active destination, and return focus or reading position predictably so users see the result of navigation. | Help the person reach a clear task outcome. | 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. |
| Good UI | A five-destination app shows a labelled bottom bar on phone, a rail with labels on tablet, and persistent side navigation on desktop while Reports remains selected in every layout. | A header shows the product name, Dashboard, Projects, Reports, Billing, a More overflow, and separate Help and account controls. | Selected state uses shape, weight, and text color instead of relying on color alone. | A mobile app bar menu button opens a left modal drawer with Inbox selected, grouped labels, account switcher, and a visible scrim behind it. | A settings page shows Account, Billing, Team, and Security in a left rail with Security expanded and Audit log marked as current. | A project detail screen shows Back, Project Apollo, Search, Share, and a More menu for secondary commands. |
| Bad UI | The phone layout calls a destination Work, the tablet rail calls it Projects, and the desktop sidebar calls it Spaces. | A crowded row mixes every page, account action, language selector, and sign-out link. | Six tiny icon-only items and a center plus button compete for space. | A drawer overlays desktop content even though users need to switch between sibling pages repeatedly. | The side navigation highlights Settings while the page heading is Audit log. | A header shows the app brand, five section links, account settings, export, delete, help, and sign out in one row. |
| Good UX | A user filters Reports on mobile, rotates to landscape, and the selected Reports route and filters remain intact in the rail layout. | Users switch from Projects to Reports, return to Projects, and find their project draft count preserved. | Switching from Home to Saved and back preserves each section's scroll count and draft state. | Users open the drawer, select Sent, the drawer closes, and Sent becomes the visible destination while Inbox scroll state is preserved. | Users open Billing, switch to Invoices, then return to Security and see the Security group still expanded. | Users switch from Details to Files and the title and primary action change together from Share to Upload. |
| Bad UX | Resizing from phone to desktop resets the current destination to Home and clears a draft. | Navigation opens external or utility destinations as if they were service sections. | Tapping Search clears the Home feed position and opens a one-off command instead of a destination. | Selecting a drawer item changes the destination behind the sheet but leaves the drawer covering the new page. | Users must reopen a drawer every time they move between sibling pages in the same desktop section. | The same Save icon appears in the header on screens where it saves, exports, or opens settings. |
| Best fit | A product supports multiple viewport widths, device classes, orientations, split-screen sizes, or foldable postures. | Users revisit several top-level product or service areas. | A compact mobile app has three to five high-frequency top-level destinations. | A constrained app needs access to more destinations than fit in the visible navigation surface. | A product area has several related pages arranged in a visible hierarchy. | A screen needs a current title plus back, close, menu, search, save, share, edit, or overflow actions. |
| Avoid when | The problem is simply choosing global navigation, bottom navigation, side navigation, drawer, tabs, or header actions for one layout. | The flow has a single ordered transaction where navigation would distract or cause abandonment. | There are fewer than three or more than five primary destinations. | Users need constant visibility of the local hierarchy while working in a section. | The destinations are top-level product areas that belong in global navigation. | The page is a public document where a simple site header and page heading are enough. |
| Required state | Compact width with bottom navigation or labelled compact menu. | Default state with product or service identity and top-level links. | Default state with all primary destinations visible. | Closed state with a clear opener such as a menu button. | Default state with the local section hierarchy visible beside content. | Default state with current view title and correct leading affordance. |
| Accessibility burden | Keep accessible names and current-page semantics consistent across adapted surfaces. | Use a labeled navigation landmark for primary navigation. | Every icon must have a visible label or accessible name. | Give the opener an accessible name such as Open navigation menu. | Use a labeled navigation landmark that distinguishes local side navigation from primary navigation. | Use semantic header, banner, navigation, and button roles only where their landmarks match the page structure. |
| Common misuse | Treating responsive navigation as separate mobile and desktop information architectures. | Listing every page or admin object in the global nav. | Putting too many destinations into the bar. | Hiding the app's most important destinations in a drawer on mobile. | Duplicating global navigation links in the side navigation. | Using the top app bar as a dumping ground for every global destination and account utility. |