| 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 | Render the same destination model in breakpoint-appropriate surfaces such as compact bottom navigation, medium navigation rail, modal or standard drawer, expanded side navigation, or header overflow without changing destination labels, selected state, or hierarchy. | 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. | Use a navigation drawer for destinations that need to be available but not constantly visible, especially on constrained screens or complex apps with secondary sections. | Use side navigation to help users move within a complex section without losing the current page's position in that section. | 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. |
| 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. | Five labeled destinations stay fixed at the bottom with Home selected, Alerts showing a small badge, and no action button mixed into the bar. | 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 hamburger opens a full-height list with no scrim, no close control, and no visible selected destination. | A sidebar mixes Dashboard, Reports, Sign out, Help, Team, API, Billing, and Marketing with no section grouping. | 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. | Switching top-level sections clears filters or drafts without notice. | 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 product has one stable navigation surface and does not change across supported sizes. | 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 product only has a few pages and does not need a hierarchy. | The interface only needs top-level destination switching and no current-view actions. |
| 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. |