September 16, 2019
A common dilemma in UX is how to handle product listings on e-commerce websites
E-commerce websites often provide the option to change the number of items displayed per page, but this functionality does not always meet customers' expectations and can cause more harm than good. In this context, a brief analysis of the issue and a potential solution for this UX problem will be discussed.
I recently came across a survey on Twitter regarding the display of paginated items that change when using the quantity filter (such as viewing 20, 30, or 40 items per page). Choosing a higher or lower amount can significantly alter the initial UX of the list, causing confusion and loss of position. This behavior is unfortunately common on the internet, and it's surprising that few websites have addressed it logically. As a regular customer of e-commerce sites, I would like to offer my perspective and a possible solution. However, I have not yet implemented it with real customers, nor do I know if the design solution is optimal. My goal is to develop logical rules so that the design system makes sense and can be tested in the field.
Let's imagine a scenario where a customer uses our e-commerce website to search for a particular item, resulting in a long list of 500 items with 25 items per page. The customer browses through three pages, viewing all the items highlighted in light cyan in Figure 1. However, the customer decides that 25 items per page is not enough and uses the display filter at the top to change the pagination to 100 items per page. The light cyan items are what the customer has already seen, while the strong cyan items are the current items being viewed. The gray items are those that have yet to be reviewed by the customer.
When a customer changes the items per page option, the usual behavior is for the entire list to reload (as shown in Figure 2), returning the customer to page one and showing the first 3 or 4 items of the list, which have already been seen. This means that everything has to be viewed again from the beginning, which can be frustrating. In some cases, the behavior is even more problematic. For example, in the past, I have encountered situations where changing the pagination leaves the customer on the same page (as shown in Figure 3) with 100 items, but the previous pages also have 100 items, causing the last viewed item to be on a previous page and leaving a large number of unreviewed items in the middle. In either case, the customer becomes lost and must browse everything again. In the second example (Figure 3), the customer must browse backward to catch up to where they left off. These issues can be extremely frustrating for customers and need to be addressed for a better UX.
This approach highlights one of the most common problems with item listings on web pages. This bad practice can go unnoticed and frustrate customers who have to waste time searching back and forth through the list, causing them to lose their place instantly. For example, if a customer is on page 5 viewing Item 223, and then changes to 100 items per page, Item 223 may now be on page 3, and the customer must navigate back through pages 2 and 3 to locate it again. Most people do not have the time or patience to calculate on which page their last viewed item is and in what order it currently appears.
The question then becomes, what is the ideal behavior for these types of cases? To answer this question, we must analyze the initial intention of our customers, which is to see more or fewer items in the list while staying in the current position. If we closely examine this premise, we can see that the ideal scenario would be to display the desired amount of items to complete the current sample at the customer's current position. For example, if the customer has been viewing 25 items per page and decides to change to 100 items per page, 75 more items should be added to the current page (as shown in Figure 4), while the previous pages remain at 25 items per page and the following pages show 100 items per page, unless the customer changes their preference again.
In this example (fig. 4) we can see the possible solution: you reload (or you don't) the page results but you just leave the customer on the same spot than before. The customer has lots of interesting and obvious options: it can go back and see exactly what was browsed or it can keep browsing the new additions and keep browsing 100 items per page. So, in an ideal world, the customer would never see a full reload, but an injection of more items to the page is browsing completing the 100, for this case. Even if the customer wants to remove it should do the same, trim the 100 back to 25 per page, the previous pages aren't changed at all.
This kind of interaction is good for many reasons: the customer doesn't experience any kind of "full reset". It will not be taken to the page 1 with 100 results, it will see the same page 3, but with 100 items. The customer has memorized two pages of items already while reviewing all, we don't change anything of that, therefore, is free to go back and find the same items has reviewed in pages with 25 items per page and move forward with 100 per page. The customer can change the filter any time, like loading 100 items and then return to 25 again, we should reload that page with the correct amount of items. If the customer re-filter again the list in any point, that page and any next page will display the correct amount of items.
To summarize, creating a good listings browsing experience requires following these rules for items per page filters:
- Never completely reset a customer's progress.
- Inject or reset the current page with the selected amount of items.
- Show the previous pages with the old options.
- Show the next pages according to the new filter.
- Any change to the filter should only update the following pages.
It's important to note that these rules do not apply to other filters, where a full reset is necessary as there is no logical option to retain the previous progress. For example, if a customer is on page 3 and changes the price filter, they must start from the beginning as they will need to review the previous pages to see the changes.