BACK button function - expectations vs. reality

BACK button. The last resort for those lost on the web. The savior of those trying to find their way through the maze of URLs and get back on track with a few clicks - the BACK button. On the one hand, it's the most frequently used navigational element of modern browsers, and on the other hand, the cause of considerable frustration.

As Christian Holst, lead usability researcher and co-founder of the Baymard Institute, notes in his article "4 Design Patterns That Violate "Back" Button UX Expectations," 59% of e-commerce sites use it incorrectly, and users expect a different performance than they experience.

Based on their research, the Baymard Institute identified four elements (areas) of websites where users felt lost and were not linked to what they thought was their previous site:

1. Layers/overlays and lightboxes - users expect the Back button to close the layer, not take them a step back in the browser path. Changing the view more than 70% tells them they are on a new page even though it's just a layer.
2. Sorting/filtering - users perceive the filtered results as a new page, even if the filters did not reload the page itself. They expect Back to undo a previously assigned filter rather than, for example, transfer to a previous step in the browser history.
3. Purchasing process where the technical steps are on the same page, even though a user may perceive them as different pages - The back button should take a user back in their steps, not, for example, take them to show an offer because that was their previous browser step.
4. Return from a show offer to the product list exactly where a user transferred from to show offer - not to the very top of the list if they were halfway through it. According to research, the malfunctioning of this option is annoying and can account for a sizable rejection rate.

Sorting/filtering Note:

• It can happen that changing the filters on the backend side (Back causes the filter to be disabled) does not cause a frontend change, and a user sees, for example, the lowest price filtering selected, even though the results have returned to the state before sorting.
• If filtering is done on a new layer (such as in mWeb versions or apps), pressing Back should close that layer, not take a user to the previous page

What else is worth paying attention to?

Beware of all steps (application states) initiated by a user, which may suggest a new page.

Various factors often influence the choice of where to return and should be selected individually (or the url path should be built accordingly). This is influenced by, for example:

• The number of steps in the purchasing process - 3 steps and returning to the first one is not a problem, but a 7-step process and returning to the first one by clicking six times BACK can be an annoying barrier.
• The amount of work, a user, puts into, for example, filling out an extensive form. If the form takes up more than 50% of the screen (often in mobile solutions), a user expects to go back in the filling process, not to go back to the previous page and delete the already completed data.
• Using the information on overlays vs expanding content - in many situations, this is a better solution because it clearly shows a user the new state of the page.
• Anchors - use of smooth scrolling vs jumping to an element - smooth scroll clearly shows a user that they have moved within a particular view, so Back should take them to where they were before on that page, not to a new page. In the case of jumping to the anchor, this is not so obvious.
• If there are a lot of jumps on the page that a user can click (or the view is not long), consider using Back as a return to the previous page to avoid confusing the navigation.
• Show more text - in this case, Back should go back to the previous page rather than wrap the expanded cluster.

To avoid the situations described above, it is worth using the HTML5 History API solution, specifically the history.pushState() function. This function allows you to customize the BACK button to work as a user expects. It allows you to add to the browsing history any visual change to the site that a user may perceive as a new page, regardless of whether it is technically a new page or not.