The Perils of Reinventing the Browser’s Back Button

There was a recent discussion in one of our projects about implementing a custom back button for our web application. The usage of a back button was inspired by mobile apps, where having an in-app back button is a standard.

Back buttons serve two purposes:

1. Allowing the users to quickly pick up where they left off
2. giving the user the feel of perceived navigation — even though no navigation might be happening at all (i.e. single-page applications).

Being able to navigate back is crucial for e-commerce or content scenarios where you want minimum browsing friction.

However, in the case of web apps, there’s already a button whose job is to go back, the browser’s back button, and reinventing it might not be the best idea; here’s why:

There’s already a back button

If your client-side app implements navigation correctly, meaning every navigation pushes a new entry to the browser’s history, then there’s nothing to worry about.

This article has great tips for taking advantage of the page’s URL to code more UX friendly features that augment the native back button’s capabilities. Particularly helpful in bridging the gap in back button behaviour between mobile and web.

And even though it’s a few years old, research tells us that users are used to the browser’s back button.

Implement additional logic to mimic the browser’s history

Many Javascript routers such as ReactRouter and NgRouter keep a history of navigations built-in, but other frameworks such as Next.js do not, thus making the feature costlier to develop.

Browser history

The final argument is that, unlike a mobile app, the browser has the history of every site/web app you visit, so what happens when the user first arrives at the site? Does that button work like the browser’s back button and executes a

, or do we want it to behave like a mobile app and not let the user leave the site? Most of the time, we want the latter; therefore, it becomes a button that behaves like the browser’s back button but with exceptions, so it is not entirely intuitive.

For instance, when the user first arrives at the site, do you decide to hide the button (and let the user figure out where the back button is), or do you show it anyway and redirect the user back to a landing page even if he has no in-app history?

A description text can enhance these buttons. This text can be a call to action different from “go back”; it can be something like “continue browsing” or “go back to <place>”. Still, that poses the question, what if you just landed on a page and weren’t browsing in the first place? Should the text vary depending on the scenario? Would users like that? Many UX considerations arise when we want a custom back button.

---

At this point, we’ve mostly talked against implementing a custom back button, but there are times where it may be useful. One scenario is displaying it alongside breadcrumbs.

When seeing the details of a product or a blog post, you want the users to view the full content and allow them to quickly go back to their previous listing so that they can continue where they left. In these cases, it is best to make the action the most expectable possible. Not all pages require a back button, so use these in pages where it’s obvious where the user will go back to. Custom behaviour such as redirecting the user to a base page or hiding the button in specific scenarios may lead to confusion which drives users away from the feature.