I have designed a 3-step form. The user will click a button that navigates to its own page without global elements to rely on getting back.

If the user doesn't want to complete the form and wants to go back to where they have come from, should we just assume the user will click the browser's Back button or should they be provided with an exit button to cancel the form process?

  • Is this form in a website/application/web application?
    – wassx
    Commented Oct 6, 2015 at 7:46
  • Thanks everyone for your comments, really appreciate it!
    – Jay
    Commented Oct 6, 2015 at 21:59
  • This is in a website.
    – Jay
    Commented Oct 6, 2015 at 21:59
  • Do you have a flow chart of the 3-step form? I see that answers below often tend to refer to a big form and stepping back. If you have some wizard style form entry, a back and an extra cancel button do have their purpose in getting back to different points in the workflow. Actions: Navigation through steps vs. Leaving form input task
    – wassx
    Commented Oct 7, 2015 at 7:20

7 Answers 7


I think the problem here is omitting any global elements from the form.

If you preserved the site header and navigation, then this problem would not exist. Perhaps you don't want the full navigation for some reason, but at a minimum there should be a reduced header with the site logo. This could be used to return to the site without completing the form.

If you think cancellation is going to be a frequent operation, it might still make sense to have a button to exit the form. But some form of site navigation is a must, in my opinion.

Apart from the need to exit the form, such branding is also important to remind the user of the context. Remember, the user is not solely focused on your site. It could be one of 20 browser tabs they have open. If they leave and return to it, will they remember what site it relates to?


Depending on the form, the user might think some of the data they entered have already been stored. A cancel button would help with this concern. But generally a cancel button is rarely needed

Jakob Nielsen writes this in his Reset and Cancel button article from April back in 2000

The Web is not an application environment, and it usually doesn't have dialog boxes. Instead, the Web is a navigation environment where users move between pages of information. Since hypertext navigation is the dominant user behavior, users have learned to rely on the Back button for getting out of unpleasant situations. Whenever users arrive at pages they don't want, they slam their mouse directly onto the Back button.

Because Back is such a strong behavior on the Web, it is usually not necessary to offer explicit Cancel buttons. If the user asks for something but doesn't want it, then you can be sure that it's Back button time.

Offer a Cancel button when users may fear that they have committed to something they want to avoid. Having an explicit way to Cancel provides an extra feeling of safety that is not afforded by simply leaving.

Read the article here, for his thoughts on the cancel button, it's very interesting. http://www.nngroup.com/articles/reset-and-cancel-buttons/

But as Dan1111 writes, it's important to have some branding on the page, otherwise the user could get confused about where he/she is, and if the form is related to the site he/she thinks it is, and start questioning the credibility of the form, and you DON'T want that!

  • 2
    That article is rather old and was written before AJAX existed. I wonder if it’s still relevant.
    – jazZRo
    Commented Oct 6, 2015 at 13:15
  • 3
    The Web is not an application environment...true in 2000 but absolutely untrue now.
    – user31143
    Commented Oct 6, 2015 at 13:29
  • @dan: But the stage has already been set. Even though it may now be an application environment, it still retains its behaviour from before this time. "Back" is an intrinsic part of the web, even to my mother who only started using web browsers and electronic devices ('smart' phones and PCs) a year or two ago.
    – user69458
    Commented Oct 6, 2015 at 17:14
  • @jazZRo what does AJAX have to do with this? I'm not sure what you mean.. With or without AJAX, it is still "just" a 3 step form.
    – Anders
    Commented Oct 6, 2015 at 21:29
  • AJAX will not be used in the form
    – Jay
    Commented Oct 6, 2015 at 22:03

It's best in every situation to give users an explicit way out. Especially in multi-page processes. Give them the Cancel button.

(Especially in modern websites, some of us expect the Back button to give unexpected results, or even break something.)


... Should we just assume the user will click the browser's Back button or should they be provided with an exit button to cancel the form process?

For best UX your application should allow the user to use any common way to get back to the page they were.

Therefore, I believe:

  1. An "Exit", "Cancel" or "Return to Page 'X'" button should be available on the form
  2. A browser back button should work correctly as well

Have a dedicated button to go back instead of relying the browser back button, it is not obvious if the user uses a mobile phone browser, so i would recommend to have a dedicated "Skip" or "Back to X" explicit to the user.

It is all based on who the user are, if they are non-technical they wouldn't be knowing about back button. Your UI should communicate what the user should do, you could not assume user knows everything.


Assuming form is opened with in browser

In this case if you are using steps to complete the forms than a back button is enough. In this case cancel or exit button is not needed. It is a good UX if an user is seeing a clean UI with very less nos of button.

Assuming form is opened in a PopUp window

Here we may need a cancel button, where clicking on cancel button it saves the form as a draft.


Tl;dr: We should treat the browser like an execution environment and not consider the browser's elements to be a part of our web application. Provide an explicit way to "close" the form and exit that sub-journey. It offers two major benefits over implicitly expecting them to back-navigate:

  • The action is predictable and controllable -- we can explicitly set the navigation target and ensure we know where the user will end up.
  • We don't require the user to step up out of the web page / web app's context to use the browser's context, which in any case doesn't offer a predictable experience with respect to navigating in forms.

To expand on that...

A few of my clients over the years have been larger organizations with employees ranging from Digital Natives to the Silent Generation, if you'll allow the Western demographics. Across the whole spectrum, something I've seen time and again is that a web browser is many different things to many different people. Having such a broad array of people has lent a few helpful lessons.

Relevant to this question, some folks are unaware of the difference between new tabs opening and in-tab page navigation. When a web application mixes navigation methods, by using in-page modals, in-tab navigation and new tab navigation for various activities, some users will quickly lose their current context and make unpredictable choices when trying to get back to where they previously had been.

Context is key.

If I open a new tab, the user has to remember

  • what they were doing in the first tab
  • where the first tab is in their tab bar
  • what they're doing in the new tab
  • that they need to close the new tab to get back to the first

It's a lot to remember and a lot of users simply don't have the same sort of fundamental understanding of what a browser is and how it works. This leads to thinking they can browse back when they need to close tabs, or close tabs when they need to browse back, or refreshing and resetting/changing session context or parameters that might not be stored in cookies, browser data or URL arguments.

When interacting with forms in web apps, clicking the back button in the browser may

  1. Take the user back an action in the form
  2. Take the user back a page in the form
  3. Take them all the way back to the previous context they were in

There isn't a common pattern universal to browser navigation in web application forms, which means we can't predict what the user will assume or attempt to do.

(To note, someone referenced a Nielsen-Norman Group article on cancel buttons and back navigation in the browser. It was excellent guidance in 2000, but it was written at a point in web history where sites and web apps were both significantly simpler and less, well, "application-y".)

Since we can't predict what a user is going to do or expect from the browser, we need to offer a method that we can control. The cancel action allows us to explicitly set a navigation target and guide the user back to where they expect to be.

Your Answer

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

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