UX Patterns Guide

Application · lesson 13 of 21 · Navigation And Wayfinding

Pagination

Underlying principle: Navigation exposes the site's structure at the moment a person needs to move. A useful route has a recognizable label, a predictable destination, and an orientation cue after arrival.

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

Start with the decision

Does this fit your task?

The collection has many ordered results.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

Navigation exposes the site's structure at the moment a person needs to move. A useful route has a recognizable label, a predictable destination, and an orientation cue after arrival.

01 / Recognize the need

What the person is doing

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

02 / Design the response

What the interface must communicate

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

First page with disabled previous control.

03 / Judge the outcome

What to look for

Does paging help users orient in the collection, or would search and filters solve the task better?

Changing page updates the collection while preserving the user's query or filters.

Practice this pattern: Sketch pagination for this situation: The collection has many ordered results. Include this state: First page with disabled previous control. Review your sketch with this question: Does paging help users orient in the collection, or would search and filters solve the task better?

Study the Navigation And Wayfinding family →Read the underlying principle →
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

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

Test the behavior

Try strong and weak versions of the interaction

Open the working example, try its controls, and compare the behavior against the decision guidance.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Pagination in the lab
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.

Failure to inspect

Using infinite scroll where users need footer access.

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

  • 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.
  • Using infinite scroll where users need footer access.
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.
  • 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.

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?
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

Source trail checked:

Saved items