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.
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
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 during our large-scale usability study of Product Lists & Filtering 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
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.
(Note that our observations on AJAX pagination pertain to an e-commerce context. User expectations might differ for, say, pagination in a comments section on a blog post.)
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.
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.
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 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.)
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.
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.