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?
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!
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:
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:
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
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
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.
