Musings on Back Button Navigation

Image Source:

Back Button Navigation

As you make your way through the internet, what do you expect when you click on the back button?

The back button has been a part of user menu selection from the beginning, it’s a hardwired mental model.

Breaking this expectation has jarring effects on a user’s experience, and confidence in the navigation.

However, the action of the back button is dictated by the way the onsite or in app navigation is set up. In short, depending on how the pages a user navigates through are set up, and how the elements on those pages are loaded, the perception of back may shift.

The application of back may not be as simple as one might expect.

How do users expect the back button to work?

The consensus is that a user expects the back button to go back to the previous page. Depending on how each action is updated to a page, this page may not actually be what the user perceives as the previous page.

What does that mean?

While checking some messages on a popular site recently, on clicking the back button I wanted to return to the main page (that I had been on before checking the messages) instead on each click I went back through all the messages I had just read. Why? Well each time I loaded a message, it loaded a new page, effectively creating a navigation trail of 7 messages before I got back to what I perceived as the previous page.

What makes a page a new page?

As the above example illustrates sometimes what the code knows as a new page is not what the users thinks is a new page. This means that what makes a new page new is determined by the user’s perception.

To continue with the messaging example, while viewing a message, if the message opens full screen when selected, the perception of a new page is created in the user’s mind. If the message opens in a pane to the side of the ‘inbox’ then the perception of a new page is not created.

Visual cues are very important in communicating what is and isn’t a new page — for example while switching between a message and the inbox, each has a completely different appearance, so must be a different page.

Unfortunately, in a lot of websites something as simple as updating a small page element like a trolley counter loads a whole new page, which is completely imperceptible to a user.

Conforming to a user’s expectations creates the necessity for a delicate tightrope walk between the technical and functional requirements which requires good analysis and probably a bit of discussion within the implementation team.

When a page isn’t a page.

While determining what the perceived previous page is in a user’s mind it’s important to consider all the actions that lead to the perception of a new page. The previous page can also be a previous state, for example when adding or removing filtering. In this case the user’s perception of the previous page is replaced with the concept of the previous data set.

Pop ups and overlays also create the perception of a new page and going back from one of these a user will expect to navigate back to where they were before the pop up or overlay appeared.

Search can also be a bit of a tricky area when it comes to determining the previous state, often while navigating through a search product set, the user will click on a product, review it and then decide to go back and look at the other options. Back to the search page, but does the page reload remember the searched term? Often this is sort of memory is sacrificed in the interest of site speed and resource preservation — or the cookies or URL haven’t been configured for this. Sometimes it’s these trade-offs that are what really add complexity to the UX tightrope walk.

Infinite scroll and pagination can also create a perception issue. When actively navigating from one page to another by clicking ‘next’ or the next numbered page, the distinction is clear. Back means the previous page. Infinite scroll creates the perception that the user never leaves the original page, but the scroll can navigate through several pages, so where does the back button go? Does it return the user to the previous ‘page’ of products, does it take them to the top of the page, or does it take them to the page before the current one?

When the back button isn’t the only option

The easiest example of this is infinite scroll, because the perception of the last page can be difficult to determine the use of the ‘back to top’ button can help provide a user distinguish which action will result in what navigation. If there is a back to top button the user knows that that the back button will not return them to the top of the page.

So it makes more sense to relate to infinite scroll through state management, like filtering.

Don’t lose their data

If a customer navigates back to their previous location, don’t lose their data, if they had searched for something, remember what it was. If they had filled in a form, whatever you do don’t make them start again. There is really only one exception to this rule, and that’s payment details — don’t keep those, it’s a risk, and in some cases may breach local protection of personal information laws.

Is it ever OK to disable the back?


If you have thoughts on this tightrope walk please add them, it is an ever evolving topic.

Beware the naked man who offers you a shirt. I'm just here offering advice, while trying to figure it all out for myself - you looking for a shirt?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store