Back to compare picker

Bottom sheet vs Sheet vs Drawer vs Bottom navigation

Choose bottom sheet when mobile users need contextual details, quick controls, or a short picker anchored to the bottom while retaining enough of the map, feed, media, or object behind it for orientation.

Decision dimensions

Dimension Bottom sheetSheetDrawerBottom navigation
UI or UX UI + UX - Mobile bottom-anchored contextual overlay with detentsUI + UX - Adaptive temporary sheet for a context-bound child taskUI + UX - Supplemental edge panel for current-context detail or light actionsUI + UX - Persistent mobile primary navigation
UI guidance Render a bottom sheet as a lower-edge surface with a visible handle, rounded top edge, safe-area spacing, meaningful peek content, and controls that remain reachable from the bottom of the screen.Render a sheet as a titled adaptive surface with clear edge or window attachment, visible close or back controls, stable actions, and sizing that matches the task.Render a drawer as an edge-aligned panel with a visible heading, selected-object identity, close control, stable width, and clear relationship to the page content it supplements.Render three to five bottom destinations with stable touch targets, labels or accessible names, reinforcing icons, selected state, optional badges, and safe-area spacing.
UX guidance Use bottom sheets for mobile contextual details or controls that benefit from lower-edge reach while preserving orientation to the current background object.Use sheets for short child tasks that need more room than a dialog while preserving parent context after the task closes.Use drawers to preserve parent-page context while users inspect supplemental detail or perform simple adjacent actions.Support rapid switching between top-level mobile sections while preserving each section's local navigation, scroll, filters, and drafts.
Good UI A map pin opens a bottom sheet with a handle, station name, distance, primary route action, half-height service details, and full-height stop list.A review follow-up sheet opens from a claim row with the title Schedule follow-up for Claim C-1042, fields, close control, compact and expanded sizes, and sticky Save and Cancel actions.A right-side case details drawer opens from a table row, names Claim C-1042, shows status, owner, activity, and a close button while the table remains visible.Five labeled destinations stay fixed at the bottom with Home selected, Alerts showing a small badge, and no action button mixed into the bar.
Bad UI A bottom panel covers the entire map immediately, has no handle, and hides the selected pin.A panel titled Sheet opens with no selected object, no close affordance, and hidden actions below an inner scroll area.A panel slides over the table with the title Details, no close control, and no selected record name.Six tiny icon-only items and a center plus button compete for space.
Good UX Users open a station sheet from the map, peek at the station identity, expand to half height for next departures, expand to full height for all stops, collapse back to the map, and keep the selected pin visible.Opening the sheet focuses the first useful field, expanding the sheet preserves typed notes, Escape triggers discard review when edits are dirty, and Save returns focus to the claim row.Opening the drawer preserves the table filter and selected row, Next item updates the drawer title, Escape closes it, and focus returns to the selected row.Switching from Home to Saved and back preserves each section's scroll count and draft state.
Bad UX Users drag on the list expecting to scroll, but the whole sheet dismisses and loses the selected map pin.A user changes the appointment note, presses back, and loses the work without a decision point.The drawer keeps showing Claim C-1042 after the user selects Claim C-1043 in the table.Tapping Search clears the Home feed position and opens a one-off command instead of a destination.
Best fit Mobile users need extra contextual detail or controls while staying oriented to a map, feed, route, media item, or selected object.A user starts a short context-bound task that needs more room than a dialog but should not become a full page.Users need to inspect object detail, metadata, comments, history, or light actions while staying on the current page.A compact mobile app has three to five high-frequency top-level destinations.
Avoid when The surface contains persistent app destinations or global navigation.The content is mainly destination navigation.The surface is mainly app navigation or destination switching.There are fewer than three or more than five primary destinations.
Required state Closed state with a trigger tied to the current map item, feed card, route, media item, or contextual action.Closed parent state with an opener tied to the object, field, or task that launches the sheet.Closed state with a clear opener tied to a specific object or page section.Default state with all primary destinations visible.
Accessibility burden Give the bottom sheet a visible heading or context label and expose it as the accessible name.Give the sheet a visible heading and use it as the accessible name.Give the drawer a visible heading and expose it as the accessible name for the region or dialog-like surface.Every icon must have a visible label or accessible name.
Common misuse Using a bottom sheet as hidden global navigation or a dumping ground for unrelated commands.Using a sheet as a catch-all panel for navigation, filters, help, settings, and unrelated actions.Using a drawer as an unlabeled junk panel for unrelated commands, navigation, filters, and help.Putting too many destinations into the bar.

Bottom sheet

UI or UX
UI + UX - Mobile bottom-anchored contextual overlay with detents
UI guidance
Render a bottom sheet as a lower-edge surface with a visible handle, rounded top edge, safe-area spacing, meaningful peek content, and controls that remain reachable from the bottom of the screen.
UX guidance
Use bottom sheets for mobile contextual details or controls that benefit from lower-edge reach while preserving orientation to the current background object.
Good UI
A map pin opens a bottom sheet with a handle, station name, distance, primary route action, half-height service details, and full-height stop list.
Bad UI
A bottom panel covers the entire map immediately, has no handle, and hides the selected pin.
Good UX
Users open a station sheet from the map, peek at the station identity, expand to half height for next departures, expand to full height for all stops, collapse back to the map, and keep the selected pin visible.
Bad UX
Users drag on the list expecting to scroll, but the whole sheet dismisses and loses the selected map pin.
Best fit
Mobile users need extra contextual detail or controls while staying oriented to a map, feed, route, media item, or selected object.
Avoid when
The surface contains persistent app destinations or global navigation.
Required state
Closed state with a trigger tied to the current map item, feed card, route, media item, or contextual action.
Accessibility burden
Give the bottom sheet a visible heading or context label and expose it as the accessible name.
Common misuse
Using a bottom sheet as hidden global navigation or a dumping ground for unrelated commands.

Sheet

UI or UX
UI + UX - Adaptive temporary sheet for a context-bound child task
UI guidance
Render a sheet as a titled adaptive surface with clear edge or window attachment, visible close or back controls, stable actions, and sizing that matches the task.
UX guidance
Use sheets for short child tasks that need more room than a dialog while preserving parent context after the task closes.
Good UI
A review follow-up sheet opens from a claim row with the title Schedule follow-up for Claim C-1042, fields, close control, compact and expanded sizes, and sticky Save and Cancel actions.
Bad UI
A panel titled Sheet opens with no selected object, no close affordance, and hidden actions below an inner scroll area.
Good UX
Opening the sheet focuses the first useful field, expanding the sheet preserves typed notes, Escape triggers discard review when edits are dirty, and Save returns focus to the claim row.
Bad UX
A user changes the appointment note, presses back, and loses the work without a decision point.
Best fit
A user starts a short context-bound task that needs more room than a dialog but should not become a full page.
Avoid when
The content is mainly destination navigation.
Required state
Closed parent state with an opener tied to the object, field, or task that launches the sheet.
Accessibility burden
Give the sheet a visible heading and use it as the accessible name.
Common misuse
Using a sheet as a catch-all panel for navigation, filters, help, settings, and unrelated actions.

Drawer

UI or UX
UI + UX - Supplemental edge panel for current-context detail or light actions
UI guidance
Render a drawer as an edge-aligned panel with a visible heading, selected-object identity, close control, stable width, and clear relationship to the page content it supplements.
UX guidance
Use drawers to preserve parent-page context while users inspect supplemental detail or perform simple adjacent actions.
Good UI
A right-side case details drawer opens from a table row, names Claim C-1042, shows status, owner, activity, and a close button while the table remains visible.
Bad UI
A panel slides over the table with the title Details, no close control, and no selected record name.
Good UX
Opening the drawer preserves the table filter and selected row, Next item updates the drawer title, Escape closes it, and focus returns to the selected row.
Bad UX
The drawer keeps showing Claim C-1042 after the user selects Claim C-1043 in the table.
Best fit
Users need to inspect object detail, metadata, comments, history, or light actions while staying on the current page.
Avoid when
The surface is mainly app navigation or destination switching.
Required state
Closed state with a clear opener tied to a specific object or page section.
Accessibility burden
Give the drawer a visible heading and expose it as the accessible name for the region or dialog-like surface.
Common misuse
Using a drawer as an unlabeled junk panel for unrelated commands, navigation, filters, and help.

Bottom navigation

UI or UX
UI + UX - Persistent mobile primary navigation
UI guidance
Render three to five bottom destinations with stable touch targets, labels or accessible names, reinforcing icons, selected state, optional badges, and safe-area spacing.
UX guidance
Support rapid switching between top-level mobile sections while preserving each section's local navigation, scroll, filters, and drafts.
Good UI
Five labeled destinations stay fixed at the bottom with Home selected, Alerts showing a small badge, and no action button mixed into the bar.
Bad UI
Six tiny icon-only items and a center plus button compete for space.
Good UX
Switching from Home to Saved and back preserves each section's scroll count and draft state.
Bad UX
Tapping Search clears the Home feed position and opens a one-off command instead of a destination.
Best fit
A compact mobile app has three to five high-frequency top-level destinations.
Avoid when
There are fewer than three or more than five primary destinations.
Required state
Default state with all primary destinations visible.
Accessibility burden
Every icon must have a visible label or accessible name.
Common misuse
Putting too many destinations into the bar.
Decision rules
  • Choose bottom sheet when mobile users need contextual details, quick controls, or a short picker anchored to the bottom while retaining enough of the map, feed, media, or object behind it for orientation.
  • Choose sheet when the task is a broader temporary child task that may attach to a side, window, or full-screen adaptive presentation rather than specifically using the mobile lower edge.
  • Choose drawer when the surface is an edge panel for object inspection or light action and side-by-side comparison with the parent page is more important than thumb reach or bottom detents.
  • Choose bottom navigation when the bottom area contains persistent top-level destinations that remain visible across screens instead of temporary contextual content.
  • Use modal bottom sheets for blocking choices or tasks where interaction behind the sheet would conflict with the current decision; use standard bottom sheets when the sheet and background can remain coordinated.
  • Use peek, half, and full detents only when each height exposes a useful amount of content; do not add detents that merely crop controls or hide the primary action.
  • Keep drag, swipe, back, close, and scrim dismissal aligned with the sheet's risk level, and preserve focus or selection when the sheet returns to a smaller detent.
  • Do not use a bottom sheet for always-needed controls, global navigation, or long-form workflows that need history, progress, or shareable state.
  • Do not replace a simple menu or action row with a bottom sheet unless the choices need mobile reach, previews, grouping, or additional context.
  • When content inside the sheet scrolls, define whether a drag scrolls the sheet, scrolls the list, or changes detent so the surface does not fight the user's gesture.
Inspect live examples
Failure modes
  • A bottom sheet opens at full height and hides the map or feed that users need to interpret the options.
  • Peek height exposes a drag handle but no useful content, so users must expand before understanding why the sheet appeared.
  • Dragging alternates unpredictably between scrolling the list and moving the sheet detent.
  • The bottom sheet contains global destinations, making it behave like hidden bottom navigation.
  • A modal bottom sheet lacks a scrim, close route, Escape or back behavior, or focus return.
  • A long multi-step form is squeezed into a bottom sheet with hidden progress and buried primary actions.
  • The bottom sheet covers persistent bottom navigation or device safe areas so key controls become unreachable.