Pagination separates groups of content into multiple pages. It typically takes the form of a horizontal list of numbers linking to each page with buttons to navigate forward and back. Pagination makes it easier for users to transverse many results by presenting them in defined amounts per page. Pagination can also improve loading time by fetching a set amount of results on each page load instead of loading everything simultaneously.
This article starts at the basic level of creating pagination and works up to complex configurations. I published the file I created to illustrate the examples in this article to the Figma Community.
At the most basic level, a pagination user interface allows the user to navigate pages. This is accomplished with an affordance to go forward and back.
A numbered representation of the pages provides the ability to go to a specific page and shows the total number of pages. Consider disabling the “back” button when the user is on the first page and the “next” button when the user is on the last page.
Truncating page navigation
When there are many pages, truncating before the first and last page allows the user to see the total page count and to go to the first and last page with one click. When the user is on the first page, only show truncation before the previous page and show truncation before the first when the user is on the last page. When a user is in the middle of the numbers, show truncation before the first and last.
First and last buttons
Sometimes, a “first” and “last” button is included in the navigation to make it explicit to the user how to go to the beginning or end page. Doing this isn’t necessary with a truncated numbered navigation because the first and last page are always present, but it can help with accessibility.
Subtle styling should still look actionable
Designers style pagination in many ways. Some user interfaces are subtle, created with just numbers and icons. However, ensure it’s apparent to the user that the pagination can be actioned and create a visual distinction for the active page.
Showing the count
Pagination sometimes displays the number of results or items per page and the total amount. Adding the amount is especially important when the user needs to manage action items in a table, like for an accounting app, but less important for lists of content, like for a blog.
Amount per page
Provide further customizability by allowing the user to define the number of results, items, or rows on a page with a simple predefined drop-down selector.
Go to page input field
Users make estimates on the page where a particular result is displayed and refine their guesses based on the content. Navigating through many pages can be assisted by allowing a user to navigate directly to a specific page by typing it into an input.
Pagination page placement
Pagination is usually found at the bottom of a page, just underneath the content it’s representing. Placing it at the bottom makes logical sense; as the user scrolls to the end of the page, they are presented with navigation options. However, putting pagination at the top of the page is advantageous when there is a very long list of items, like in the case of a data table with 500 rows. Scrolling to the end of the table to interact with the pagination would be a poor user experience. It is better suited above the content and fixed to the top as the user scrolls. Alternatively, you could place the pagination at the bottom but fix it on the page so it’s always visible.
Data table bulk selection actioning considerations
Actioning a bulk selection across multiple pages on a paginated data table creates an interesting user experience issue. What happens if a user makes selections on one page, navigates to another page, makes further selections, and then does a bulk action? I’ve seen this handled in a few ways, but this is an area I’d like to investigate further. Please share what you think in the comments.
In general, selections should be able to span multiple pages, but there should be an indication of how many things are selected and on what page. The user should only be allowed to do a bulk action on their current page unless there is an obvious confirmation dialog indicating what items will be affected.
Pagination or infinite scroll?
Instead of dividing content into separate pages, infinite scroll progressively loads new results as the user moves down a page. Infinite scroll can be a great option for exploration and discovery use cases like those on a social media feed. However, infinite scroll isn’t the best option when users need to find, compare, manage, and action-specific items like on a bookkeeping app.
When numbered navigation isn’t needed
Including a list of numbers in a pagination UI isn’t always helpful. For instance, calendar interfaces benefit from a simple forward and back UI that can also go to the present day. Blogs and other media websites don’t usually benefit from showing numbers. And even some heavy data table UIs don’t require numbers to achieve user goals. Always let the user’s needs dictate what UI patterns you implement.