UX Patterns Guide
UI + UX Navigation And Wayfinding standard

Pagination

Split the collection into stable pages with current page, previous, next, and reachable page controls.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The collection has many ordered results.
  • Users may need to resume at a known page or position.

Avoid when

  • Users need uninterrupted reading or comparison.
  • The result set is small enough to show at once.
  • The choices are sibling content panels rather than ordered slices.
  • The result order is unstable enough that page numbers will mislead users.

Problem it prevents

Users need to move through a long ordered collection without loading or scanning everything at once.

Pattern anatomy

What a strong implementation has to make clear

User need

The collection is too large for one screen or one request.

Pattern promise

Split the collection into stable pages with current page, previous, next, and reachable page controls.

Required state

First page with disabled previous control.

Recovery path

Changing page without updating URL or state when shareability matters.

Access contract

Use a labeled navigation region.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Current page, previous/next, disabled edges, page numbers, result range, and total count are visually clear.
  • Controls stay stable while loading and remain near the results they paginate.
  • Users move through pages while query, filters, and sort persist.
  • Current position is clear enough to resume, share, or recover after changing filters.
Weak implementation

Vague, hidden, hard to recover from

  • Tiny numbers with no current state.
  • Pagination jumps around as pages load or separates controls from the result list.
  • Changing page resets filters.
  • Using pagination where users need side-by-side comparison across pages or stable footer access is required.
UI guidance
  • Render a labeled pagination nav near the affected results with current page, previous, next, nearby pages, optional first/last or ellipsis, and clear disabled edge states.
  • Show result range, total count, and preserved query/filter/sort context so users understand what slice they are viewing.
UX guidance
  • Help users move through an ordered result set with a stable sense of position, progress, and returnability.
  • Preserve query, filters, sort, page size, and focus context while changing pages; recover clearly from out-of-range pages.
Implementation contract

What the implementation must handle

States

  • First page with disabled previous control.
  • Middle page with previous and next available.
  • Last page with disabled next control.
  • Loading state after requesting another page.

Interaction

  • Changing page updates the collection while preserving the user's query or filters.
  • The current page is exposed visually and programmatically.
  • Users can move by keyboard without losing context.
  • Previous and next move one page relative to the current page and become unavailable at collection edges.

Accessibility

  • Use a labeled navigation region.
  • Expose the current page with aria-current or equivalent text.
  • Give previous, next, numeric, first, last, and ellipsis controls accessible names.
  • Controls follow normal button or link focus order.

Review

  • Does paging help users orient in the collection, or would search and filters solve the task better?
  • Can users tell which results they are seeing and whether their filters persisted?
Interactive lab

Inspect the states before you copy the pattern

Move through result pages

Step between pages and inspect whether the current page and disabled edges are obvious.

Pagination
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

First page with disabled previous control.

Keyboard / Access

Controls follow normal button or link focus order.

Avoid Generating

Using pagination for a tiny collection.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Pagination

GOV.UK Design System - checked

GOV.UK documents previous/next, current page with aria-current, pagination landmarks, ellipses, and applying filters or sorts to the whole list.

USWDS Pagination

U.S. Web Design System - checked

USWDS documents bounded sets, current page highlighting, first/current/previous/next/last visibility, and edge behavior.

Carbon Design System Pagination

IBM Carbon Design System - checked

Carbon documents placing pagination under related table or page content, current-page information, item ranges, and responsive behavior.

MDN aria-current Attribute

MDN Web Docs - checked

MDN documents aria-current="page" for pagination links and limiting current state to one item in a related set.

Full agent/debug reference

Problem Context

  • The collection is too large for one screen or one request.
  • Users need a sense of position in a result set.
  • Users may need to keep the same query, filters, sort, or page size while moving through results.

Selection Rules

  • Choose pagination when result order, bounded position, and resumability matter.
  • Show current page, previous, next, first/last or nearby page controls, and disabled or hidden edge behavior clearly.
  • Preserve query, filters, sort, and page size while moving between pages.
  • Use filtering or search first when users are trying to find a specific item rather than browse positionally.
  • Use load more or infinite scroll only when users do not need stable page position, footer access, or shareable page state.

Required States

  • First page with disabled previous control.
  • Middle page with previous and next available.
  • Last page with disabled next control.
  • Loading state after requesting another page.
  • Current page state exposed with aria-current.
  • Out-of-range or empty page recovery after filters change.

Interaction Contract

  • Changing page updates the collection while preserving the user's query or filters.
  • The current page is exposed visually and programmatically.
  • Users can move by keyboard without losing context.
  • Previous and next move one page relative to the current page and become unavailable at collection edges.
  • Result count or range communicates what slice of the collection is visible.

Implementation Checklist

  • Persist filters and sort while paging.
  • Label previous, next, and numeric page controls.
  • Handle empty or out-of-range pages.
  • Avoid shifting page controls while content loads.
  • Use aria-current="page" on exactly one current page control in a pagination set.
  • Keep pagination visually near the content it controls.

Common Generated-UI Mistakes

  • Using pagination for a tiny collection.
  • Resetting filters when moving pages.
  • Hiding the current page or total position.
  • Using page numbers for unrelated topics or sibling sections.
  • Making previous or next appear available when there is no page in that direction.

Critique Questions

  • Does paging help users orient in the collection, or would search and filters solve the task better?
  • Can users tell which results they are seeing and whether their filters persisted?
Accessibility
  • Use a labeled navigation region.
  • Expose the current page with aria-current or equivalent text.
  • Give previous, next, numeric, first, last, and ellipsis controls accessible names.
Keyboard Behavior
  • Controls follow normal button or link focus order.
  • Disabled edge controls are not misleadingly focusable.
  • After page changes, preserve context and announce the updated result range or count.
Variants
  • Numbered pagination
  • Previous and next only
  • Cursor pagination
  • Load more

Verification

Last verified: