4 Design Patterns That Violate Back-Button Expectations

During all our usability studies we’ve observed how users, both novice and expert, rely extensively on the browser back button. Often this has severe usability implications in these modern days where we design webpages with overlays, toggled states, accordion checkouts and one page applications. These new-fangled web design patterns often have a default technical structure which break user expectations and clash with the user’s mental model for how the decades-old browser “back” button functions.

The consequences of breaking the user’s expectations of how the browser back button should behave can be dire. During our usability tests it has been the direct cause of abandonment, with users leaving test sites under much swearing and cursing (even from the well educated, mid-aged and otherwise calm test subjects).

In this article we’ll go over 1) how users expect the back button to work, 2) five of the most common pitfalls, and 3) a simple solution to all of this. While the solution is simple, it’s surprisingly often neglected in the implementation phase – even on the largest websites, as you’ll see below, and especially on mobile sites.

How Users Expect the Back Button to Work

The short version: users expect the back button to take them back to what they perceived to be their previous page. The notion of perception is the key factor here, since there’s often a difference between what is technically a new page and what users perceive to be a new page – which can create discrepancies between where the user expects the back button to take them and where it actually takes them.

At the center of the issue is what users interpret as a new webpage. Generally we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one – regardless of whether it technically is a new page or not. This has consequences for how your website should handle elements like overlays / lightboxes, accordions, form submits, pagination, and filtering.

“When I click ‘back’ here I expect to go back to my search results… But I don’t. Come on, this is so ridiculous. But my search is kept intact.”

Much the same way users have little technical understanding of website security and instead go with their gut feeling (learn more), they similarly show little appreciation for the (often arbitrary and minute) distinctions of when a new view is technically a new webpage or just an expanded element on the existing page. And therein lies the rub: the browser back button takes the user back to their previously visited URL, which isn’t necessarily the same as what the user perceived to be their previously visited page.

Users therefore often rely on an element’s visuals, its context, and prior site experience, when shaping their expectation of when something is a new webpage vs a slightly altered element on the same page. It’s the outcome of this subconscious snap judgement that determines where the user expects the browser back button to take them.

Below is a walkthrough of the 4 website elements we most often observe to be implemented in ways that break user expectations – that is, where the user isn’t sent back to what they perceived to be their previous page when using the browser back button.

1) Overlays & Lightboxes

Here a subject tried clicking the back button to close an overlay which appeared after he clicked an item at Gilt. Much to his surprise he was sent entirely off the site and not back to his prior view (without the overlay).

Overlays and lightboxes are by design meant to convey a new page that’s laid on top of the of previous page. It should therefore come as no surprise that users perceive these as separate pages and expect the browser back button to bring them back to the original page. Alas, during testing, the vast majority of user-initiated overlays at the tested site did not close as the subjects clicked the browser back button, and instead sent them way back past the overlaid page.

This is particularly unfortunate since users often act very negatively towards overlays on e-commerce sites, with the majority wanting to close them instantly (as described in section 4 of Avoid These 5 Types of E-Commerce Graphics).

2) Filtering & Sorting

Filtering and sorting generally yield an entirely new product list and users therefore perceive each of these actions as distinct view. Even when the filters or sorting directions don’t invoke a page reload, we still found the subjects to generally perceive each discrete iteration of their filtering as a new view (most likely because it is a user-initiated action and each iteration produces a new set of results).

This underscores how users don’t make technical distinctions between what is and isn’t a new page, but rather rely on what they perceive to be a new page. Filtering and sorting, of both categories and search results, should therefore support that users flick back through each list state by using the browser back button.

3) Accordion Checkouts

“Arhh no. Do I have to start over? Now I’m getting angry. Doesn’t it have my shit already [referring to his already typed address and card info]. Now I’m leaving. This isn’t a serious store.” During mobile checkout at Foot Locker, a subject clicked the back button after having progressed and filled out all the required information in the payment step. Alas, he was sent all the way back to the cart and all his typed data was lost. The quote speaks for itself.

Contrary to what one might think, accordion checkouts are not perceived as a one page checkout with multiple collapsed sections. Instead the vast majority of users perceive them as a multi-step process with summaries (more on how users perceive accordion checkouts). This can turn out problematic on sites where the accordion steps are technically implemented as a single page with one URL, as users wanting to go backwards to a previous checkout “step” (e.g. to edit previously entered information) will be sent all the way back to the cart.

4) AJAX Pagination

Ajax pagination can be vulnerable to breaking user expectations as it doesn’t technically have to invoke a browser history event as new pages are opened. In an e-commerce context most users will however have a clear expectation of results “page 3” being separate and different from “page 4” – and consequently they expect to be able to go backwards through their pagination history using the browser back button.

If It Looks or Feels Like a New Page

The four above examples are typical mismatches where users often expect one thing to happen yet sites are implemented in a way that causes something else to happen. However, this type of misalignment goes beyond those common examples. Generally you should watch out for all new views states initiated by the user which either look like, or conceptually feel like, a separate page.

This subject explores two different options at IKEA’s “Seating Solutions” inspirational images. Each is a thumbnail which expands to fill the entire page width when clicked. After having opened the first one, the subject wanted to go back: “Nah, let’s go with the previous one.. hey! What happened here!?” The back button took him all the way back to the main category page as the expanded options weren’t part of the browser history.

While you may sit down and identify some of the most obvious cases throughout a site, it often requires actual user testing to reveal when users conceptually perceives something as a new page. This is especially true for site owners and employees who have a unique understanding of their own site and therefore often perceives it differently from users – in particular first-time visitors.

Users Rely Extensively on the Back Button

This mismatch of users expecting the back button to take them back to their prior view when in fact it sends them back to the prior URL can clearly cause issues if not dealt with appropriately. Given how extensively users rely on the browser back button this issue should not be taken lightly.

“You really have to be goddamn careful not hitting those help links while typing.” After accidentally tapping a “Help” link, this subject tried using the browser back button to get to his previous page, but it didn’t take him back to where he had progressed to – instead it took him two steps backwards in the checkout process.

Especially mobile users rely extensively on the browser back button. During our usability study of mobile commerce sites, the vast majority of subjects used the back button throughout all of the tested sites. And it wasn’t just a single page they went back. Many subjects went multiple steps backwards in their browsing history – 3-6 repeat taps on the back-button wasn’t unusual, with the subjects sifting back through shopping carts, product pages, applied filters, search query iterations, and more. (Indeed, during the mobile commerce study, a subject in one instance tapped the browser back button 15 consecutive times!)

We also observed consecutive clicks on the back button during our latest e-commerce category navigation usability study, although it wasn’t as frequent as on mobile. On desktop sites, users often decide to re-find prior visited pages using the site navigation (categories or search) instead when they want to go far backwards in their browsing session.

The Solution

The good news is that HTML5 brings us a relatively straight-forward solution to this whole mess: the HTML5 History API. More specifically, the history.pushState() function allows a site to invoke a URL change without a page reload, meaning the site can align the browser back button behavior to match user expectations. (The reverse is also possible: to change the URL without invoking an entry in the user’s history.)

When observing test subjects open their order receipt emails (first image), some tried closing Gmail’s overlay for viewing attachments using the browser back button (second image). Fortunately this worked as the subjects expected and returned them to the order receipt email. (Image is a reconstruction)

This means that when opening, for example, an overlay, the site can invoke a history change in the user’s browser, allowing the user to “go back” from the overlay view by using the browser back button. And this of course goes for anything, including: user-initiated overlays and lightboxes, AJAX-based pagination, filtering and sorting of lists, accordion checkouts – any element which the user would expect to have invoked a browser history but technically hasn’t.

Therefore, use the history.pushState() to create a new entry in the user’s browser history for any view that the user will perceive as a new page (i.e. any view that is sufficiently different visually or conceptually to be perceived as such). This way, you can ensure that site behavior and user expectations align.

Use Judiciously

While the history.pushState() function can be applied to just about any view with multiple states it’s important not to overdo it. This power should be used judiciously.

For example, it would typically be overkill to record the individual slides of a carousel as separate entries in the user’s browsing history. When the changes recorded in the user’s history are too minor, the user simply grows frustrated when trying to go back in their history as they have to sift through a barrage of miniscule element changes. Users generally also don’t expect uninitiated page changes to invoke new entries in their browsing history, and elements like automatic campaign “pop-up” overlays should therefore not invoke a browsing history entry when autoloaded.

In summary: Use history.pushState() to make sure your site invokes ‘back’ button behavior that aligns with the user’s expectations. Specifically, ensure that any visual change the user will perceive as a new page is added to their browsing history, regardless of whether it’s technically a new page or not.

Comments (9 so far)

On a related note, it is worth mentioning a fairly common technical bug that often wrecks the user’s back button functionality, namely intermediary redirect pages. These intermediary pages only exist to redirect the user to another page, which isn’t a problem in and of itself. However, when they are implemented poorly, they can effectively break the ‘back’ button functionality by creating a redirect loop which sends the user back to the page they were already at.

We often observe subjects being caught in such redirect loops, particularly after adding items to their cart or submitting a form. While users can technically double-click or expand their browsing history and jump multiple steps backwards (thus bypassing the redirect loop), this very rarely happens in practice.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

It’s ironic to have an article about not breaking the back button, on a site where the ctrl+click (open link in new tab) functionality is broken. Thankfully, middle mouse click still does what I want. I definitely didn’t expect ctrl+click to take me off this page though, as it generally always opens a new tab.

This really is a fantastic article! (I actually don’t remember now from which site I opened a browser tab to load this article a day ago, because after loading this article’s link into a tab I only returned to read this a day later).

It’s not often that I read UX usability studies that cover subject matter I haven’t previously come across. The examples provided here are all excellent and prompt me to want to visually these scenarios in my head and sketch them out, or find other examples and screenshot them for analysis.

One thing I wasn’t particularly clear about was what you included as “AJAX Pagination”… I have not conducted testing in this area, have not paid for test results in this area, have not sought out results of testing in this area, that’s from my own prioritization of what I find most important in my work. So I am sure I go against the grain of many UX designers. But I have never seen any value at all to endless scrolling of pages. If this was concocted for mobile, ok… But I think its practice has “broken” far more than it has fixed.

You distinguish between e-commerce sites which have liked page numbers for results lists — and — blog comments. I personally can’t stand not being able to communicate to a friend, family member or colleague and give them a specific URL in which to find specific reader-posted content, such as:

… and the reason I can’t provide a URL is because of the LACK of URLs with “endless scrolling”… Yes, it’s true that some implementations of endless scrolling provide permalinks to each comment, but I actually find that a lot of such comment sets do not, which is incredibly frustrating. It leaves me a regressive choice of having to screenshot some content, scroll down, screenshot next page view, and email the two picture files to recipient. Still not a great solution because one of the purposes of this interactivity is to REPLY TO: Person X’s comment … and if you can’t locale person X’s comment amidst all the pageless reader comments (let’s say with HuffingtonPost), it’s just a terrible user experience..

So, how this ties into the BACKBUTTON is that you cannot find the same placement of Commenter X’s comments within 250 comments to the article as you scroll forward and miss finding it, and try hitting BACK-BACK-BACK to try to find the darn comment.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

Thanks for the article!
From my standpoint being a mobile expert, I can only agree with the points raized by the author, which are also applicable to mobile apps. HTML5 is a great solution for the issues described.

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.

Post a comment!

You need JavaScript to comment. Unfortunately we've had to require JavaScript to deal with comment spam.