Skip to content

Design

The Sticky Bottom Bar is a persistent UI element at the bottom of the viewport. It keeps primary actions — like saving progress or submitting data — always accessible regardless of how far the user has scrolled. The pattern improves mobile usability by anchoring primary actions inside the thumb zone.

Anatomy

Section titled “Anatomy”

Add a phone number to continue.

  1. Bottom Bar
  2. Status message
  3. Action button

When to use it

Section titled “When to use it”

Use the Sticky Bottom Bar when:

  • The page involves high-volume scrolling and the user needs constant access to primary actions.
  • You need to display real-time global feedback or validation errors while the user interacts with fields far from the bottom of the page.
  • The content exceeds 150vh (one and a half times the screen height), such as long forms.
  • You want to improve mobile ergonomics by placing primary actions within the thumb zone.

Avoid the Sticky Bottom Bar when:

  • The page is static and the user isn’t inputting or saving data.
  • All fields and the submit button fit within a single viewport — the bar adds unnecessary visual clutter.
  • The component would sit inside a modal — modals already contain their own button bar, and adding a sticky bottom bar leads to scroll-jacking and a cramped UI.
  • There are no data-entry actions — the bar serves no purpose and distracts the user.

Properties

Section titled “Properties”

Appearance

Three appearance states map to the form’s status: Empty form (buttons appear disabled), Error message (a concise red message appears beside the buttons on tablet/desktop, above them on mobile), and Successful form (the primary action becomes active).

Status message

Inline text used for global validation feedback. Renders inside a polite live region so screen readers announce updates without interrupting the user’s current focus.

Action button

A primary Button-Main at LG size. Secondary buttons may appear alongside the primary, but the submit verb should always read as the primary action. Disabled buttons should not receive keyboard focus — surface a clear error on click instead.

Platform considerations

Section titled “Platform considerations”

Desktop

The bar spans the viewport width with the status message and button(s) arranged on a single row. Keep the bar’s elevation distinct from the page surface so it reads as a separate layer.

Tablet

Same one-row layout as desktop. Make sure the page content has bottom padding equal to the bar’s height so the last form field isn’t hidden behind it.

Mobile

The bar reflows to a one-column layout — status message above, buttons below. The thumb-zone position is the whole point of the pattern at this size.

Best practices

Section titled “Best practices”

Use the bar as a workflow tool — it should help users finish, not chase them down the page.

Do

Use it for critical editing workflows where users save changes frequently, lean on it for dynamic feedback when validation messages need to be visible from anywhere on the page, place primary actions in the thumb zone on mobile, and add bottom padding to the main container equal to the bar’s height so the last field never hides beneath it. Pair it with the Stepper for multi-step forms, and use it when content exceeds 150vh.

Don't

Don’t use it for short forms that fit in one viewport, don’t nest it inside a modal that already has a fixed footer, and don’t include it on pages without data-entry actions — the bar serves no purpose and distracts the user.

Content guidelines

Section titled “Content guidelines”

Submit button labels should name the action the user is about to take (“Save”, “Continue”, “Submit”) rather than generic verbs. Keep status messages concise and specific — name the field or rule that needs attention so the user can act (“Add a phone number to continue”) instead of restating that something’s wrong. When the form has multiple steps, the bar’s wording shouldn’t change between steps — predictability is the point.