Pagination testing should show whether someone can find the right record beyond the first page and return to their work without losing context. A public SaaS demo that only opens page one leaves that question unanswered, even when the pagination controls look finished.
For a developer building in public, this is a useful task to share with founder peers. Give them a safe dataset, a specific record to locate and a reason to open it. Then observe where the route becomes unclear. You get a more concrete conversation than asking whether the new table looks good.
The following test plan uses a fictional invoicing product. It is a proposed workflow, not a report of testing a real product. All customer names, records and situations should be synthetic in any public version you create.
Start with a record that is not immediately visible
Create enough sample invoices to require several pages at the page size used in the demo. Put a known target somewhere beyond the first page, and record its identity in your private test notes so you can check what the peer eventually opens.
The task might be: find the unpaid invoice for a named fictional customer, open its details and return to the invoice list to continue checking overdue work. Do not tell the reviewer which page contains it. That would remove part of the navigation question.
Include plausible distractors. Two invoices might belong to the same sample customer but have different dates or payment states. The point is to see whether someone identifies the correct record, not merely whether they can operate a Next button.
Before inviting anyone, confirm that the task is possible with the supplied account and data. A reviewer should not need access to your development tools, private database or personal explanation to complete the route you are asking them to assess.
Establish what pagination is doing
The U.S. Web Design System's pagination guidance describes pagination as dividing content across pages. Its guidance also covers navigation labels, the current page and testing an implementation in its own context. Using a familiar component does not verify the surrounding product flow.
In your demo, explain what one page contains. Is the list filtered to unpaid invoices, or does it show every invoice? Does the page indicator refer to the current filtered set? Can the reviewer tell whether additional results exist?
Avoid adding implementation detail that the reviewer cannot use. They do not need a description of your database cursor to say that they expected another page of unpaid invoices. Developers can investigate the technical cause after the task exposes the confusing behavior.
If the list has a changing or unknown total, describe that honestly. Do not display a precise final page merely because a static mockup had room for one. The interface should reflect what the product actually knows about the available results.
Change the filter while away from page one
After the reviewer has moved forward, ask them to limit the list to a different payment state. Observe what happens to the current page and the visible explanation of the results.
A useful question is whether the new view makes sense on its own. If the filter leaves fewer pages than the previous view, does the product show a useful result or an unexplained empty table? If it moves to the first page, can the reviewer understand that they are viewing a new set?
Do not assume there is one correct page-reset behavior for every product. Write the intended behavior for your workflow, then compare it with the actual experience. The test should expose a mismatch between the chosen design and the task, rather than enforce a rule you never considered.
Repeat with a filter that deliberately matches no records. A legitimate empty result needs a different explanation from a failed request. Ask the peer what they think happened before you explain it. Their answer may reveal whether the state communicates the distinction.
Sort the collection, not just the visible rows
Give the reviewer a task that depends on ordering across pages, such as finding the oldest unpaid sample invoice. Then ask them to change the sort order and explain which record they expect to appear first.
Check whether the behavior matches the product's stated scope. If a control is presented as sorting the whole list, sorting only the currently loaded rows would create a misleading route through the collection. A polished arrow beside the column name would not resolve that problem.
Include records with equal values in the chosen sort field. Watch for records appearing twice or disappearing while the reviewer moves between pages. These observations are reasons to investigate ordering and page boundaries; they are not enough by themselves to diagnose a particular backend defect.
Record the relevant conditions with the observation: the selected filter, sort direction, page and target record. A report that simply says pagination is broken gives a collaborator far less to reproduce.
Open details and follow the return path
Once the reviewer finds the target, ask them to open it, inspect a safe detail and return to the list. Let them choose the return control they naturally notice. That may be a product link or the browser's Back button.
Look at what survives: the filter, sort order, page and enough position context to continue the task. The product may deliberately reset some state, but that choice should fit the work rather than happen accidentally because the list remounted.
Now ask the reviewer to locate the next invoice they intended to inspect. If they must rebuild the previous view from memory, note the extra work and ask what context they expected to keep. Avoid coaching them through the return route while claiming they completed it independently.
Check the same path after reloading the details page when that is a supported product action. A navigation flow that works only when entered from one particular demo sequence can be fragile for someone following a shared link later.
Notice keyboard access and changing data
Run a separate pass using the keyboard. Check whether the pagination controls can be reached and operated, whether their labels explain the action, and whether the current page is conveyed. Inspect your rendered implementation instead of assuming the component library guarantees the result.
Also decide what the test should do when the sample collection changes. You can add or remove a synthetic record between page visits and observe the outcome. Keep that controlled change separate from the first usability pass so you know which conditions produced the observation.
A moving collection may need different behavior from a stable report. The test's purpose is to understand the tradeoff you have implemented, including whether someone can still find a known record. It does not require promising that every list will remain identical while other users change it.
Share the task and the limits of the result
Buildside is a place for founders to share progress, questions and lessons. A public-building update about pagination can include the task, a safe demo link and one question about the route through the records.
Publish what you changed after reviewing the observations. Distinguish a peer finding the right invoice from a peer saying that the list looks clean. Both can be encouraging, but only one directly answers the retrieval question you set.
Preserve useful uncertainty. One founder completing the task does not establish that every customer, browser or access method can do so. A failed attempt may reveal an interface problem, an unsuitable task or a broken demo account. Investigate before generalizing.
Your next release note can be concrete: what navigation behavior changed, why it mattered to the task and which paths you rechecked. That gives developers and potential users a visible account of the work. Pagination becomes more than a row of controls when the public demo follows a real task all the way back to the list.
Hey I'm Uriel Bitton. I write about building in public strategies and growing startups.
Subscribe for more stories on growing your audience by building in public.
Join us on Buildside: the social network for founders building in public.
