Pagination: a lazy interface decision or a useful design pattern?

Posted Friday, August 7th, 2009 by Walt Buchan

A client asked me the other day ‘is pagination really necessary for my FAQs page? The developers say it is, but I’m not so sure’.

Here’s an example of the pagination in question:
Example of pagination

This got me thinking, when is pagination actually useful and does it support anything apart from navigation?

My opinion, when I began looking into the subject, was that pagination could be seen as a lazy option for an interface, sure there are circumstances when it seems useful but who does it help?

So what’s wrong with paging through this content?

TIP: User requirementsDiscover what your users really want and need by defining their user requirements.First impressions are that paging through four pages of content shouldn’t really be a problem, should it? However closer inspection shows that the 36 items of content cover quite a range of subjects. Do you really want to click through four pages when you know what you want, why couldn’t you just see it straight away?

So pagination has hidden the information you need to make a decision about what to read. To make matters worse the information is listed randomly so there’s no clue to be had from the list order. The randomness of the list is compounded by the addition of a indication of popularity. The list items are not ordered by popularity, nor can they be sorted by popularity and what would popularity tell you anyway? Why was one FAQ more popular than another? What relevance is popularity to the users current task?

Paginating the FAQs results in users having to view every page and then to read each item before they can decide which is relevant to them. That’s a lot of thinking to do for a casual glance at a list of FAQs.

Oh yes, there was an argument that pagination allowed users to download pages quicker over slow connections. All four ‘benefits’ pages, about 500Kb, would download in less than a second on todays broadband connections, so pagination doesn’t speed things up – it slows them down.

How could these FAQs be designed differently?

There’s intelligence that could be wrung from the site’s analytics data that would make it easier for people to find what they wanted.

  1. Extract more intelligence from each FAQ. Each FAQ is unique but several will cover the same general subject so identify this subject and use the higher divisions to divide the FAQs up.
  2. Indicate the divisions and provide navigation so users can get the relevant information.
  3. Structure the FAQs so you can order them alphabetically and indicate what element of the FAQ has been ordered.
  4. Possibly provide alternative sorting options, if that is relevant, e.g. recency
  5. Potentially gather intelligence about where the user has navigated from, show them the FAQs that are relevant to what they were looking at last.

Useful pagination

Example showing Google's pagination

The classic example: Google

A simple list of page numbers enhanced with navigation to move forward of back works wonders when all you have to navigate is a largely unstructured set of data. The only structure here is relevancy, generally the items at the top of the list are of interest. cxpartners have witnessed some interesting variations in search behaviours from test participants purposefully viewing lower ranked pages (usually associated with a self created search engine superstition).

Pagination also helps to indicate abundance and may nudge a user toward redefining their search to get a more manageable list of results.

Long list of Google's paginated pages
There are good business reasons why Google paginates too, more of that later.

Pagination for structured data

Frequently information on the Internet is structured, and that means that pagination can be more helpful to the user. People try to make sense lists by looking for a pattern. This is something we see all the time in user tests whenever results are listed, be they products, photographs, or messages. Expectations might be; for products to be listed by ascending price, photographs by recency, messages in chronological order.

Giving data a structure allows it to be filtered, sorted and broken down in to relevant groups of information, for example:

HMV

Screen shot showing HMV's paginated music section

HMV provide users with an array of options to sort the information, they indicate: status, abundance and progress. Layered on top of these options the information is ordered alphabetically, just like in a high street music store. Users can link directly to the section of the store they want. There are plenty of less structured ways to browse for music but if you’re in a hurry you can right to the music.

Linkedin

Linkedin think about the tasks that users will be engaged with and support them. When you’re logged in to Linkedin, contacts are presented as a scrollable list with alphabetical links. It’s just like an old fashioned contacts Rotadex card holder – it fits the task and model of looking for contacts perfectly.

Scrolling through content is a desktop metaphor and you rarely find desktop applications that include pagination as a primary method of navigation. So why include pagination on a web application?

Screen shot of Linkedin's list of contacts

When you browse other peoples contacts on Linkedin there’s no more nice scrolling. It’s back to pagination:

Screen shot showing Linkedin's pagination on other contact's lists

The priority is no longer the user, after all beyond browsing a contact you can’t do anything whilst on a contact’s contact list. But Linkedin can – they can show you advertising. Every time you visit a new page they can show you some more ads and then some more after that. The priority is now the business.

When we looked at Google, I mentioned the business case, and it’s the same one. Every click through to a new page equals increased advertising revenue. maybe people do only look at the first page of Google but there’s no harm in placing ads on subsequent pages too.

What have we learned?

The old arguments for pagination no longer hold true, content needn’t be broken up into discrete pages, generally download speeds can handle a long page of text and images these days.

We’ve also seen that pagiantion can only really support unstructured information, like Google search results. When information has structure, or more importantly when users expect it to have structure, then pagination fails to support the user’s task.

When information is structured, it supports users by allowing them to see, and manipulate the structure and navigate through it. If there is already a broadly accepted mental model of how the information is structured (e.g. Linkedin contacts) support it, and develop around it.

Pagination on its own rarely helps users, but it can help a business model that relies on page views to drive revenue by keeping users on the site longer and getting them to view more pages. A rough rule would be that if a business model relied on conversion then pagination should only be used with care, anything that gets in the way of conversion is bad.

Pagination is often one of those design decisions that gets left to the last minute or proves a struggle as you patiently arrange numbers, forward/backward arrows and then wonder what happens if you have 5000 pages not the tidy ten pages you’ve designed.

About the author

Walt Buchan
Walt has spent the last 11 years working with the web. He has a background in design and production and enjoys ethnographic research. He’s renovating his house at the moment, so he’s doing a lot of D.I.Y at the weekends! Email Walt, or call +44 (0)117 946 3930

Tags: , , ,

Further reading

9 Responses to “Pagination: a lazy interface decision or a useful design pattern?”

  1. Greg Woods

    Nice article. I agree, pagination is used too much as the primary means of navigating long lists.
    Either categorise better for users who browse (dabs.com is good at this), or add more intelligence and better sorting for users who search. If there are still lots of results, lazy loading is usually better than paging. For waaay too many results, either guide the user towards a narrower set, or as a last resort, paginate.
    One problem is, fine tuning search results, for most web sites, is not even on the list of priorities. It is invisible, is a time sink, and it doesn’t tick any boxes on the customer’s requirements list. The paying customer is often too short-sighted to care about individual end user experiences.

  2. James Carmichael

    Walt,
    Thanks for this informative and detailed post.
    I think that as touchscreens become the norm, pagination and website navigation in general is going to need a big rethink.

  3. Walt Buchan

    Greg, If I’ve understood your post correctly, I’d say that a client that doesn’t recognise the importance of the individual end user experience perhaps shouldn’t have any individual end users.

    Supporting end user behaviours and delivering a delightful end user experience is likely to be the first opportunity a company has to deliver first rate customer service. A poor experience on the web is no different from a poor experience in a high street shop or with a call centre. If you or a client has a poor experience do you go back for more? Or do you tell your friends to steer well clear? I know what I do.

    I don’t think the link between customer service and success is in any doubt, however for websites the investment is largely technical and upfront rather than in ongoing human resources and training.

    James, You’re right, established design patterns may not survive the cut as new interactions become the norm. But, as with deciding whether to use pagination, it’s the user that should be at the centre of design decisions, closely coupled with the commercial goals of the organisation.

  4. Stewart McCoy

    Great article! I’d questions about implementing pagination to increase readability for an online magazine, but it seems after more thoughtful consideration this is an ill-advised idea.

    Also, I’m not quite sure the LinkedIn icon fits in with the “share” icons at the bottom of the article. Stumbleupon, Facebook, Twitter, Delicious, and Digg are all methods of “sharing” the article, but the LinkedIn icon isn’t quite for sharing, but learning more about cxpartners by visiting the company’s profile. So, not that the LinkedIn icon shouldn’t be there, but my expectation is to share the article via LinkedIn, not to view cxpartner’s company profile.

  5. Walt Buchan Walt Buchan

    Hi Stewart, Thanks for the comment glad you found the post useful, it’d be great to see your online magazine. Good point about the LinkedIn icon, we’re looking into that right now. Walt

  6. Stewart McCoy

    Walt, the magazine I’m referring to is one I write for while on fellowship in graduate school. It’s a transportation magazine for teens that explores careers in the industry. It’s published by Iowa State University’s Institute for Transportation and you can read the magazine at http://www.go-explore-trans.org. Thanks!

  7. kylec

    Glancing through your post, not sure if you mentioned it, but another useful way to handle pagination is with clear descriptive labels rather numerical ones. In the case of FAQ’s, I’d imagine it might be better to try and categorize the FAQ’s and chunk the pages up based on those categories, rather than 1, 2, 3, etc..

  8. Puzzled

    I find the article somewhat confusing. Does the author mean “pagination without sorting” when he refers to ‘pagination’?

  9. Walt Buchan Walt Buchan

    Hi kylec, I think you’re absolutely right to suggest that clear labeling and chunking the content up in to categories would be a good idea. Too often pagination is used as a band-aid, instead of really getting to grips with the information architecture of a website.

    Hi Puzzled, You’re assumption is spot on, thanks for the comment.

Leave a reply