Should a web-based UI rely on the browser back button?

  • The back button is a great "get out of a flow's dead end" option that browsers provide. Should a UI rely on the back button as the only method to allow a user to get to the previous page or should the UI provide an additional, site-specific button to return to the previous screen?

    A common scenario that comes to mind with this is an eCommerce site that has a list of products. A user clicks on one of the products to view a details page. Then after viewing the details, they would like to go back to the list to click another product and view its details. Should the UI assume a user will use the browser back button or should the web site provide a link or button that allows users to "Go back to Your Results", leaving the browser back button as an alternative option?

    Whatever you do, don't cut the browser's back button out of the picture. There is little more frustrating (especially on mobile) than hitting back and getting "Confirm Form Resubmission" instead of the previous page.

    @aslum I absolutely agree. The back button has been referred to as the "2nd most used navigation feature". http://ux.stackexchange.com/questions/36017/is-the-browser-back-button-still-the-second-most-used-navigation-feature I ask the question because the popularity of the back button is likely (I have no source for this) related to a poorly crafted user flow; "I don't know what I did to get here, but this isn't the page I want. Time to hit the back button." If we crafted a good flow that includes going back in pages, should the back button be the only tool or should we offer an alternative?

    I can live with "Confirm Form Resubmission". That serves a valid security purpose and keeps me out of trouble. The one that really drives me insane is clicking Back and, rather than going back, returning to exactly the same page!

    I've grown accustomed to using my middle mouse button on web applications like you describe. I open product details in another tab and close the tab to "go back". One advantage is you never have unexpected results after pressing the back button, another is that your scroll position within the listing doesn't change. Navigation is a big pain with the majority of web apps out there, I've seen very few do it exactly right.

    Rely on? No. Account for? Absolutely.

  • taswyn

    taswyn Correct answer

    6 years ago

    A web application should always strive to be compatible with the browser's back button. That is, using the back button should have deterministic results within that application that match expected behavior (global consistency).

    A common scenario that comes to mind with this is an eCommerce site that has a list of products. A user clicks on one of the products to view a details page. Then after viewing the details, they would like to go back to the list to click another product and view its details. Should the UI assume a user will use the browser back button or should the web site provide a link or button that allows users to "Go back to Your Results", leaving the browser back button as an alternative option?

    However, a web application should generally not rely solely on the browser's back button for all navigation that might be considered related.

    Sadly, one of the top reasons for this is that some people are afraid of hitting their back button within certain web applications due to broken or inconsistent browser control/state related behavior found in many AJAX heavy web apps, where using the back button may not result in the effect the person using it anticipated.

    Secondly, if the page was spawned from a new tab (or a bookmark!), there may not be a back button. While the person using the app should ideally still have the original tab open, if you want them to be able to access the page they came from, make sure to give them a way to do so from the context of the page they are currently on.


    Using your example, say the list was a static sale page (instead of a dynamic search). What if the person browsing the site bookmarks an individual product, then closes that session. When they load that bookmark, what navigation options do you want available to them? What navigation options do you think they will want at hand? It's a good idea to make these a consistent component of your UI, hence not worth solely relying on the back button in other instances.

    To expand slightly on this, providing back-navigation options within your UI gives you control over their presentation: this means you can assuage anxiety over what an action result will be by clearly delineating what using the control will do.

    For example, consider whether someone would have any uncertainty over what the following might do:

    • Back (Back to where? also applies to the browser's back button, because we all know it doesn't always do what we expect, depending on the web app, and people don't know what your app will do until they try, which can be a hesitation point)
    • Back to listings (which listings? if I come here from a bookmark, do I have any clue what I was doing that got me here?)
    • Back to [associated product category] (Well, that's nice, it is functional and not a concern for failing to be deterministic, but should probably be represented elsewhere)
    • Back to the January Sale Event (hey! that's what I was looking at when I came here! it's specific enough that I can expect to end up… where I would expect to go) (aka it matches the navigation context map that brought me to this page)

    (and you probably want to use a wording such as "More of" rather than "Back to," depending on the context you end up using such a control in, and when the navigation from it clearly ties to specifically cross-related results)

    That last example gives you what you want to strive for: a reduction of anxiety for people using your application by making clear what the related outcome will be.

    Moreover, this gives you extra behavior beyond what is necessarily available in just the back button. While the back button should simply work, this control is then present if someone opens the page two months later. If they do click on it, you can present the related page for the "January Sale Event" but with a message at the top saying the event is now over, we're sorry you missed the amazing deals we were having, but see [these new events/products/etc].


    These navigation points are an opportunity not only to have a backup back-navigation control that you know the person using the application will feel comfortable interacting with, but also one where you control where it goes, and which provides you an opportunity to communicate with the user under a fairly tightly managed context. They can, if managed correctly, provide more functionality than the browser's back button alone does, enhancing the experience rather than simply cluttering the screen with directly duplicated controls/functionality.

    If you are going to implement back-navigation controls, make them clear, consistent, and consistently available (at least on the page types where they make sense). Try to provide extra value over what the back button alone represents, both to yourself and the people using your application.

    If you are just going to literally duplicate the browser's back button functionality with a control that says back or has some similarly representative icon… don't bother. Just make sure the browser back button behavior works properly. (which you should always be doing anyway)

    Agreed. Don't mess with the back button. Websites that did this were a problem in 1999 (Jakob Nielsen, The Top 10 Web Design Mistakes of 1999 and are still a problem today.

    Yes, it's very much a case of two wrongs don't make a right: make sure the back button works in an appropriate, consistent fashion. I've shadowed so many people while training/etc & they've hesitated at a back navigation task and then turned to ask if the back button would work or spent time hunting for some other control rather than just using it—but that's not an excuse for breaking it too. It can be an argument for supplementing it, though, especially with anything showing explicit action outcomes. (especially key around state change operations, e.g. progressing through a form or cart)

    I've found this answer useful so many times while developing mobile interfaces that I felt you deserved more than just a single upvote from me - so have a well deserved bounty.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM