Pagination Component Visual QA Workflow from Figma

Pagination looks correct in a mockup with ten pages and page two selected. It breaks when there is one page, 1,284 pages, a filtered result set, a narrow phone, or a translated Previous label. The visual defect is often small; the navigation error behind it may strand users or send them to a page that no longer exists.

Pixelay lets designers and developers compare Figma frames with live, staging, local, or private web pages using overlay, split, difference, and other comparison modes. Pagination QA still needs deterministic data and functional testing. Pixel alignment cannot prove that a URL, focus change, or result count is correct.

Define the pagination contract

Before taking screenshots, agree on:

• page-size options and default;
• first, previous, next, and last controls;
• how many numbered pages remain visible;
• the ellipsis rule near each boundary;
• whether page numbers live in the URL;
• behavior after filtering, sorting, deleting, or adding results;
• narrow-screen treatment;
• focus and announcement behavior after navigation;
• empty, loading, error, and end states.

If the product uses cursor-based navigation, do not design exact page counts the API cannot provide. If it uses infinite scrolling, this article is the wrong test plan. Name the interaction honestly.

Create a state matrix with fixed data

Use seeded fixtures so Figma and the implementation describe the same collection. At minimum capture:

State	What it reveals
zero results	pagination should disappear or become inactive
one page	unnecessary controls and spacing
first page	previous and first-control behavior
middle page	selected state and both ellipses
penultimate page	shifting number-window logic
last page	next and last-control behavior
many pages	condensation and large-number width
loading	layout stability and duplicate navigation
error	recovery without losing the current location

Add a data change while the user is on the last page. If deleting the final item makes that page invalid, define whether the user moves to the previous page and what is announced.

This workflow is different from data-table visual QA, where pagination is one part of a dense grid, and tabs component QA, which switches peer panels rather than navigating a result collection.

Capture comparable Figma and browser states

Create one Figma frame for each approved state at exact target viewport widths. Seed the staging or local environment with matching totals, page size, labels, and selected page. Record the URL and fixture identifier so another reviewer can reproduce it.

Use Pixelay to align the implementation with each frame. Overlay mode is useful for spacing, control dimensions, selected indicators, and baseline alignment. Split view is useful when dynamic browser rendering makes a transparent overlay hard to interpret. Difference views can reveal one-pixel drift, but not every colored region is a bug; antialiasing and native text rendering may differ.

Check:

• container width and alignment with the results;
• target size and spacing between controls;
• icon geometry and optical alignment;
• selected, hover, focus, disabled, and pressed treatment;
• ellipsis spacing and non-interactive appearance;
• two-, three-, and four-digit page widths;
• Previous and Next labels in longer locales;
• layout stability while new results load.

Test narrow layouts as a decision, not a squeeze

At small widths, the design may hide first and last controls, reduce the numeric window, switch to Page 3 of 18, or use only previous and next actions. Capture that behavior explicitly. Do not let CSS wrapping decide the information hierarchy by accident.

Test at the exact boundary where the desktop layout changes. Look for controls wrapping onto two lines, the selected page becoming obscured, ellipses being mistaken for buttons, or a sticky mobile bar covering the last result.

At 200% zoom, the navigation should remain usable without horizontal collision. Long localized labels should not shrink below readable size merely to preserve the desktop arrangement.

Pair visual comparison with functional checks

Navigate with a keyboard. Focus order should follow the visual sequence, and the focused page must be obvious. Disabled controls should not behave like links. The current page should be exposed programmatically, commonly with aria-current="page", and controls need names that make sense out of context.

After changing page, decide where focus goes and how the new result range is announced. Avoid unexpectedly moving focus to the browser top. Confirm back and forward navigation restore the correct page, and direct URLs open the intended state.

Test sorting and filtering from a later page. Many products accidentally retain page=8 after a filter leaves only two pages, producing an empty screen that looks like no results. Test page-size changes and permission-dependent result totals as well.

Write bugs that separate appearance from behavior

A useful visual report says:

At 390px on fixture catalog-184, the selected page indicator is 6px shorter than the Figma frame and the Next control wraps below the row. Expected the compact Page 8 of 19 layout shown in the mobile design.

A behavioral report says:

On /catalog?page=8, applying the Open filter leaves two pages but preserves page 8, producing an empty result area. Expected reset to page 1 with the result count announced.

Keep those findings distinct. Pixelay supplies strong comparison evidence; the browser, accessibility tree, URL, and network state supply functional evidence. The visual bug report workflow can help standardize the handoff.

Sign-off conditions

Pagination is ready when all boundary states match approved designs, responsive rules are explicit, focus and selected states are visible, long labels and large counts fit, and result loading does not cause disruptive movement. Verify URLs, history, filters, page-size changes, invalid pages, keyboard behavior, and announcements separately.

A single middle-page screenshot proves almost nothing. Good pagination QA makes the boundaries visible, reproducible, and difficult to misinterpret before customers discover them one page at a time.

Read as Markdown · Related resource index · Site index for AI agents