Years ago, when I was working at Nylon Technology, I was designing a data management system for one of our global law firm clients. As I was fleshing out one of the internal landing pages for Attorneys, I added a paginated list of all the attorneys, starting with the first 10, listed alphabetically. This approach wasn't out of the ordinary. Then, Simon Free casually walked over to my desk and dropped a bombshell of a question:
Why would anyone want to see the first ten attorneys when they get to this page?
It was like one of those dreams where you show up to class naked and have to give an oral report on a topic you've never heard of. Suddenly, nothing made sense. It felt like the floor fell out from under me. This may sound like an overstatement; but, when you're job is to design and build usable workflows and you can't even explain how or why someone would use your design, it rocks your world. It's like a punch to your emotional gut.
This happened over a decade ago and the feeling has haunted me ever since. It was a wake-up call and a reminder that the answer to a user experience (UX) question can absolutely never be:
When we have very small lists of data, it's easy to dump that data onto the screen with the assumption that it can be quickly scanned by the user. And, that such simple access holds its own reward in terms of curiosity and discoverability. But, what happens when that list of 10 things becomes a list of 10,000 things? As a user experience designer, it's easy to say, "paginate it". But, what is the real user experience (UX) of pagination?
| || || |
| || |
| || || |
Pagination never happens in a vacuum. It's there to solve an access problem for the user. But, in order to solve that problem, we have to understand what the user is trying to accomplish. And, we have to embrace the fact that this is a dynamic problem that is very context sensitive.
How many of you, when given the option in an e-commerce site, select the "Show All" link next to the pagination widget? I know I do. Every single time it's available. We do this because, as users, we inherently understand that there is some amount of data that can be more easily consumed in a single set. And that waiting for that set to load is worth some additional friction (ie, load time).
But, let's think about Amazon.com for a moment. I enjoy pagination in an Amazon.com search result. And yet, at the same time, I never want to see a paginated list of all of their products the moment I get to their homepage. In one case, the pagination facilitates a real use-case, "How do I find a specific product or type of product." But, in the other scenario, pagination is omitted because the use-case, "How do I look through every product Amazon.com sells," is simply not valid. And, designing against it would be, at best, a serious waste of design, development, and infrastructure resources.
I think most user experience designers actually understand this. But, that they fall back to pagination as a default approach because they aren't sure what else to put on the page. Part of that stems from not really knowing how the user would want to consume the data. But, I think an even bigger part of that comes from a fear of empty spaces. There is often a strong desire to avoid white-space. But, we have to remember that white-space is a tool, not a problem.
There is nothing inherently wrong with pagination. It's a great way to make data accessible without overwhelming the user. But, before you can paginate, you have to know what the user is looking for and whether or not pagination is an actual value-add. And, if you can't answer that without saying "Because, data", don't give the user data - give them a way to tell you what their intent actually is.
I think paginitation is one of those few things that we can say: "The more choices the better."
Nice article and reminder to take a step back and look at the bigger picture, Ben. I know it was 10+ years ago, but do you remember what ended up on that page instead of the paginated list of attorneys?
Agree, a nice article. It seems that there is no one answer - as in "it depends".
It depends on how much data will be returned to the web/control, what other ways of scrolling through the data are available, and what are the normal methods for this type of data.
I've tried fully scrolled lists of thousands of items (slow loads and heavy browser utilization), selectable pagination, infinite scrolling (good and bad). Of course limiting the amount viewable by any type of filter is a good thing but it doesn't always help with product catalogs that range up to 10's of millions of records.
Amazon tends to sort by some preference (whether theirs [to sell] or yours [to get a good deal] but still will present in paged mode.
Let us know when you nail down the optimal for all cases!
Disappointed, Ben! I thought you were working up to revealing a brilliantly clever way of reinventing pagination. :-) If you have a lot of data then it's always best to give users simple data mining tools to help them narrow down what they're looking for. Not just a search tool, but related filters like how eBay does. And then once filtered you can still travel through pages of more relevant results. When there are photos associated with records it's nice to scroll through loads since your eye can pick up the image much faster than having to read through text.
Sometimes a random result is of interest. You don't always know what you're looking for - sometimes a result can find you rather than you having to find it!
Actually, yes. We ended up just putting a search form (with multiple filter inputs). We did use pagination, but only *after* the user performed a search. And, I believe we increased the number of items per-page. And you know what, no one ever complained about not having "enough stuff" on the landing page.
> Let us know when you nail down the optimal for all cases!
Ha ha ha, probably will never happen. But, I think that's exactly the point. Every case is different and just slapping pagination on the page is never the answer.... unless it is. The point is, you have to consider the context, the data, the intent, etc.. In my particular case-study (10 years ago), we didn't eliminate pagination altogether - we still used pagination in the search results. But, the big deviation was that we didn't show a "default list". We waited until the user entered a search query (and filtering) and *then* we did the search and showed a paginated list.
Ha ha, sorry to disappoint :D
> Not just a search tool, but related filters like how eBay does
Yes, 100% agree. And, to that point, you can really only do that when you truly stop to think about your users, the data, and the likely modes of data access. Then, you can give them the right tools to find the relevant data.