88

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?

Improve this question
6
  • 61
    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
    Mar 2, 2015 at 17:37
  • 3
    @aslum I absolutely agree. The back button has been referred to as the "2nd most used navigation feature". ux.stackexchange.com/questions/36017/… 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?
    – Benjamin S
    Mar 2, 2015 at 21:20
  • 10
    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!
    – Michael Hampton
    Mar 3, 2015 at 12:32
  • 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.
    – MarioDS
    Mar 19, 2015 at 20:45
  • Another question about the back button: ux.stackexchange.com/q/7216/95
    – Jørn E. Angeltveit
    Apr 22, 2015 at 13:36

13 Answers 13

Reset to default
86
+50

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)

Improve this answer
3
  • 5
    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.
    – Greenstone Walker
    Mar 5, 2015 at 3:07
  • 2
    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)
    – taswyn
    Mar 5, 2015 at 22:58
  • 2
    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.
    – BiscuitBaker
    Apr 23, 2015 at 11:33
28

Yes. You should rely on the browser back button.

Users expect the button to be there, so make sure it's functional.

But should you mimic the same button with its functionality?
If your application or website needs it, yes, but not always exactly the same.
In some cases, like your example of a webshop, a button that just says back or an arrow might not be sufficient. In this example a breadcrumb navigation is in order, or a button or link that says "back to results" (some more context for the user's sake).

Improve this answer
9

Rely is the wrong word

You're asking if you should rely on the button, which you shouldn't. You're also asking if you should offer another option. Which you could, and in certain situations, should.

So here's the thing:

Back button

You should never, ever, break the behavior of the back-button. At all times, you must strive to keep it's functionality in tact, as it's part of the behavior of every single browser out there. It's a user's handle on the situation, their help in case of error.

It's a life-vest which you shouldn't remove.

Your own UI

In a lot of cases, things like a crumb-trail or a "back" button could be useful. Maybe because the browser's back-button is hidden on a certain OS, maybe because it's slightly less sophisticated, or maybe just to keep users looking at your app instead of the browser.

In general, you can't really go wrong with adding some courtesy navigation.

Conclusion

Should you rely on it? You can, as long as you make sure not to break it when you don't. Should you add your own? If it seems convenient, if you'd use it, yes.

And lastly: measure. See if people use it if you do add it.

Improve this answer
2
  • I think Dirk has a great point at the very beginning of the comment. Rely is the wrong word. You should not "rely" on the fact that a user will use a browser back button over a different type of navigation style. The most important factor is that you support the browser back button. Our applications should not break native behaviors.
    – vernonk
    Mar 3, 2015 at 19:41
  • 1
    Great points. I upvoted for the importance of that last sentence: "And lastly: measure. See if people use it if you do add it."
    – Benjamin S
    Mar 4, 2015 at 20:08
5

I usually try to provide both on-screen back-button and support for browser back-button.

Reasons:

  • If the user is immersed in the flow of the app, an on-screen back button can help keep focus inside the flow and avoid losing the user's attention.

  • Supporting the browser back button is important to me, even at great cost, because it's presumptuous design to assume the user will just use the on-screen button rather than the browser's back button.

Note that there are some rare exceptions where you want to intentionally avoid or break back button behavior (e.g. security forms).

Improve this answer
3
  • 4
    Breaking the back button is never ok, not even in rare cases. If the user is not permitted to submit a form twice, that is to be checked at submission time, not when the user clicks back to the form. The reason it is never ok to break the back button is, that the user may need to click the back button multiple times to go back past your page and possibly end up on a page which isn't even part of your app. (I consider it a design flaw in the browser, that it is even possible for a webpage to break the back button.)
    – kasperd
    Mar 2, 2015 at 21:35
  • @kasperd in UX I've tried to stay away from the word 'never' :-) In all seriousness, I think there are many examples where it makes sense to break the browser's native back behavior. When content is loaded via Ajax, or when you don't want users to be able to navigate back to a one-time security page, it's common to use history.pushState() or history.replaceState() to break the native browser behavior for very solid UX reasons.
    – tohster
    Mar 2, 2015 at 21:53
  • 1
    It may be a design flaw in the http spec, rather than in the browsers that implement that specification. The spec allows the client to send a POST request, which cannot be safely repeated without the user's permission and get a page to display in response. Maybe the spec should not have allowed that.
    – bdsl
    Mar 2, 2015 at 22:31
2
  • the browser back button MUST work as expected.
  • your web UI back button MUST NOT provide a back button unless it does the same thing the browser back button does
    • example: filtered category view in ecommerce - if the back button return to unfiltered category view it MUST NOT look like a back button, but rather like a breadcrumb.
  • you SHOULD provide contextual navigation links, but they MUST NOT look like back buttons

The main reasoning behind the back button behaviour argument - take this example scenario:

  • I filter our products with price < 1000
  • I click one product to get to the detail page
  • I click the "ui" back button
  • I see category page with all items
  • as customer I think "I clicked the back button and the filters are lost" (and therefore there is no reason to try browser back button)
  • I swear proportionally to the complexity of the filtering I had set up
  • If there was no "ui" back button I would most probably just use the browser's back button as I'm used to.
Improve this answer
2
  • You've stated a lot of this as absolutes without giving any reasoning why. I'm nod disagreeing with you, but please edit your question to include the reasoning behind the suggestions.
    – JohnGB ♦
    Mar 4, 2015 at 12:36
  • 1
    My argument is purely anecdotical. Although - see update.
    – Tomáš Fejfar
    Mar 4, 2015 at 12:48
2

One should not solely rely on the back button.

Why?

Because Smart phones on average are growing at a faster rate than humans hand sizes. Look at where these back buttons typically are.

Top right (general) Back Button for menus Iphone standard view (bottom left) enter image description here Iphone 6 horizontal view (top left) enter image description here

Now lets take a look at how users hold their devices enter image description here enter image description here

Sometimes its difficult to reach that back button because users hands arnt large enough to easily hit the default back button in all positions. Thus if its possible to provide an easier way to traverse do so.

See this trend in regard to screen size enter image description here

Another reason to not rely on the back button is because there may be scripts preventing a user from going back and getting the result they expect due to the website design

Improve this answer
5
  • You make some good points about button position and button size for mobile layouts, but I'm afraid it focuses more on how specific smartphone OS user interfaces place and size their back buttons.
    – Benjamin S
    Apr 23, 2015 at 20:07
  • Thanks @BenjaminS your 100% right. I answered this pretty late and I didnt want to replicate any of the prior content that was covered pretty well here.
    – Frank Visaggio
    Apr 23, 2015 at 20:15
  • 1
    um.... the back button is at the bottom on iPhone LOL and most Androids
    – quemeful
    Mar 10, 2018 at 18:01
  • Your title is confusing to read. "No one should not solely rely on the browsers back button." is the same wording as "One should solely rely on the browsers back button."
    – David Baucum
    Jul 30, 2021 at 20:27
  • @DavidBaucum thank you for that grammar was awful. I think I updated it to make it somewhat more clear. also as per the back button in the bottom in 2015 that was less common it appears apple and android have put it in an area that is easy to access regardless of our growing phones sizes.
    – Frank Visaggio
    Aug 17, 2021 at 18:54
1

I believe that you should not rely exclusively on the browser's back button.

  1. If the user is interacting with your site to get somewhere, I think it's reasonable they would expect to be able to return the same way.
  2. Displaying where the user is within the context of the website is important so the user has a frame of reference where they are in the overall site.

*edit for clarification: you should definitely support the browser's back button as well. Just want to make sure that was clear. I was just adding on the reasons you would not want to exclusively rely on the browser's back button.

Improve this answer
1

No, you shouldn't rely on the browser's back button.

While its easy to say that you can expect it to be present and that you can expect it to always function a certain way, that's simply not the case.

Because the back button exists in an application outside of your own, you can't reasonably expect it to be present or function in any specific way. If there's anything that the Responsive Design revolution has taught us, its that you can't predict anything about the context of a user's browsing.

What if, in 2017, Google decided they didn't want to support the back button in Chrome anymore?

We can cry heresy all we want at the moment, but Google could do that for any number of reasons that we cannot predict. So could M$, Apple, Mozilla, or any other browser vendor. Then you're left relying on a feature that no longer exists.

Improve this answer
1

There's a lot of stuff here about not removing or interfering with the browser back button but I don't think that's what the questioner is asking.

The Browser's back button is there for the user and shouldn't therefore form a part of your projected user journeys. The user may have customised their browser so that the back button does not show - If you are relying on this then you will end up with a broken user journey.

I wouldn't rely on anything that's likely to use the JavaScript "history.back" function either (effectively a back button press).

If your user journey shows that a user is likely to want to skip back to a search results page or somewhere else then you should provide an explicit method for them to do this - "Go back to Your Results"

Improve this answer
2
  • you are absolutely correct in your first sentence. There is no question about the importance of leaving the back button alone. The real question is, should the UI provide a similar tool.
    – Benjamin S
    Apr 22, 2015 at 16:22
  • ...and that's what I dealt with in the other three paragraphs ;) I hope you got an answer that works for you Benjamin!
    – Roux Martin
    Apr 23, 2015 at 8:22
0

I wouldn't use it exclusively.

The first example that comes to mind is Google Chrome for Android. Every "tab" is a new instance, and so opening a new window is akin to starting a brand new session. In these instances, the back button will simply take the user to the homescreen instead of actually going back. The same thing will happen if a user chooses "Open link in new tab".

Due to that functionality, having some navigational function on the website would allow the user to keep going without breaking the flow of things.

As a side note: I have somewhere between 40-100 tabs in Chrome because of this. It is really quite easy to accumulate tabs by using the browser normally, and not all users will actually know how to deal with this behavior.

Improve this answer
0

Speaking not as a designer but as a user; anytime I have to default to my browser's back button to continue navigating a site, I can't help but consider it a failure of the site's UX. The more I have to use it, the more frustrated I get. The only exceptions are instances like "What was that seller's address on the last page?" or "What did I put in that form field on the last page again?", with the intent of returning directly to the page I'm already on.

IMHO, the native back button should never be the user's only way out of a page, even if they're trying to return to a previous listing page. There are myriad simple, tested, effective options to provide navigation for your users - a < back to listing link at the top of a page, breadcrumbs, or any of the other answers' suggestions work well.

Improve this answer
-1

I would expect that the back button just brings me back exactly to the last page where I have clicked on a link or submit button. Like "Open in New Window", closing the new window, and bringing the first page to front again (as MDeSchaepmeester describes above). The browser should not send a single bit over the network, just fetch the page from cache exactly like it was; no re-submittal of the form (booking another room in the hotel), no side-action at all.

As the back-button is ill-specified from the beginning (see bdsl's comment) and does something different on every browser (recently Google decided that Chrome's back button clears forms, which broke my puristic scientific data site which was unchanged since 1998 and relied on the back button), you should do everything to keep the user from pressing the back (=random) button, but provide your own, easily understandable navigation tools.

Improve this answer
3
  • Welcome to the site, @Peter. If I'm understanding correctly, you appear to be suggesting that the website should put the onus on the user to use an in-page button rather than the browser's built-in button. This approach seems like it would give a bad experience for the many users who are in the habit of clicking the browser's back button and may not even notice your in-page back button. Can you explain why you believe that trying to force users not to use the browser's back button provides a better experience (better than having one button or having two consistent buttons)?
    – Graham Herrli
    Nov 14, 2015 at 0:18
  • Because the back button behaves different in every browser; as said, on Chrome it goes back to the last page, but it erases all form fields. I'm using a small textarea with a save button in my website, where the users can add notes to a chronological list. If they find a typo in the result, the usually press the back button, correct the typo, and save again. This works in all browsers, but for the newest Chrome. As the result of the back button is not predictable, it cannot be integrated in any reasonable user interface.
    – Peter Steier
    Jan 3, 2016 at 17:14
  • Chrome now has changed: the back button reloads the page (and resubmits, if it was left by a POST), and then magically inserts the last field entries into the new page. Must have been fun to program this, I wonder how they handle it if the "reloaded" page happens to have different fields now.
    – Peter Steier
    Aug 13, 2020 at 7:33
-2

You should rely on the browser back button but not exclusively! Best case scenario:

  • back button on the screen
  • support for browser back-button
Improve this answer
2
  • 1
    Can you expand more on why it shouldn't exclusively rely on the back button?
    – BDD
    Mar 2, 2015 at 19:19
  • my best case scenario explains it. have both options at all time
    – zizus
    Mar 2, 2015 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.