Cancel button vs back navigation

hi all,
I searched for this topic but it seems not covered yet. If is already discussed my apologies :slight_smile:

I need your POV regarding a page with a list and each list is linked to a page with a web form.
As a user:

    • what do u expect to move back and forward between pages?
    • why do u prefer having cancel button?
    • why do u prefer having back navigation?

here a quick and dirty example:

Step 1 - The list

Step 2 - The web form Version 1

Step 2 - The web form Version 2

I always prefer cancel, because these days there are so many apps that autosave, if I havenā€™t specifically cancelled something Iā€™m not sure that Iā€™ve undone the action.

2 Likes

Same - I need to know Iā€™ve undone it and not committed to anything I donā€™t want to.

I expect to see back buttons as well- I like to be able to go back and change details eg shipping information when shopping. In that example I have three postal addresses (home, work, po box near my husbandā€™s office and he checks it) depending on where Iā€™m shopping and how they post it, I like to be able to go back and edit the details.

2 Likes

thank you ladies @HAWK and @AshleaMcKay,
the application (responsive) Iā€™m working on is pretty huge and with several processes.
What we want to achieve is to provide our DEVs a standard for:

  • navigation between list and detail page.
    Most of our lists are triggered by filter panels. We were wondering if if more usable to provide a cancel or back to help users going back to the filter page (preserving the filter status)

  • navigation between web form pages and overview pages.
    For example, users are entering payment details and before confirm the payment itself they land on a preview page where to check all the data

We are discussing about the navigation (back to) vs function (cancel, kill the process). My personal POV is that as a user I expect cancel (same behaviour of the X button) in a dialog and not in a page and/or in a process

What do you think about it?
I wish you a great Sunday
Luigi

What do you mean by a process? I think I would expect cancel in a process, but need clarification.

Itā€™s 6:40am on Monday here in Auckland, and itā€™s a freezing winter morning! :slight_smile:

1 Like

In this specific case it is a payment process. We are building a feature to allow users to pay slips. It is very close to a wizard process:

  • step 1, users choose the slip (based on colors)
  • step 2, users enter the basic data, a couple of codes and the system is able to fill-in the form according such codes
  • step 3, users define how much they have to pay and when
  • step 4, users receive a resume with all the data and the ā€œpayā€ button is visible
  • step 5, users receive the invoice and they can download or print

in the current solution for each of those step we are displaying a ā€œback toā€¦ā€ link

P.S. I will pay more attention to the time table :slight_smile:

Yeah, I think that makes sense in a wizard type process. Iā€™d expect ā€˜backā€™ to take me to the previous step without keeping any changes in the current one.

[quote=ā€œdopamino, post:6, topic:1325ā€]
P.S. I will pay more attention to the time table
[/quote] Heh, itā€™s all good. It was Sunday for everyone else. :slight_smile:

I agree, but some customers asked for a cancel button for each step, as well, to kill the process quickly.
In a nutshell:
back= go to previous step and change your data
cancel= I do not want to go trough this process anymore
Iā€™ve the feeling is too muchā€¦

Ah. In that case I think it makes sense.
I was thinking you meant ā€˜cancel this current stepā€™ rather than ā€˜cancel this entire processā€™.

exactly, they want the cancel button reacts as the ā€œXā€ button for the dialogs. Iā€™m still not 100% sure that we are not overloading users in this way.

Makes sense to me! I donā€™t think thatā€™s too much - you donā€™t want to be taking control away from the user.

What is it about it that has you thinking youā€™re overloading users?

Have you tested it that way?

I think that weā€™re overloading users because they will think about the meanings of back and cancel.
For another project (different scenario was an e-commerce platform) users were confused about the process behind each of them.

We are going to run a qualitative test next Friday, I want to check both approacches

1 Like

Sounds like a solid plan! Looking forward to hearing what you find out!

I will let you know :slight_smile:

1 Like

We performed a qualitative test with 8 people.
Each session was focused on two tasks where users have to perform several ā€œgo backā€ actions:

  1. users have to go through a process starting with search query that brings them to a search results page and afterwards to a detail page

  2. users have to go through a process starting from a list page (choosing one single option) to a web form page and landing on the preview page after the submission

here the most valuable findings:

  • for the task #1 - 6 users on 2 clicked on the browser ā€œback arrowā€ to go back. They were pretty clear explaining that they strongly prefer to use the browser navigation instead the app navigation (breadcrumb and back buttons)

  • for the task #2 - nobody clicked the back button (positioned on the top left corner of the page). All users clicked on the ā€œcancel buttonā€ close to the ā€œapplyā€ button at the end of the fieldset

Due to the fact that we are not providing any breadcrumb within the app we are going to deliver the process without the back navigation button. We will provide the cancel button at the end of the web form to allow users to kill the process and go back to the previous screen.

1 Like

Why wouldnt I as a user want both options?

I want to cancel when I have made changes but dont want to commit them.
I want to go back when I have made changes that I want to commit.
Otherwise I would need to restore the original state before I go back.

1 Like

I donā€™t want to demonstrate, in general, that there is a wrong approach or a good approach .
Iā€™m working on a framework to build web-banking apps.
Our goal is to provide components (we are developing according atomic design approach) that allow internal developers and third parties developers to build views and pages following a standard UX logic.

For instance one UX KPI are performances. The back navigation costs a lot (especially when we have to build the user journey within different app sections) in terms of performances, to our architecture, if users do not use such feature we do not want to deliver it.

This is the reason why we run usability test (qualitative and quantitative) with customers. We want to highlight the ā€œmost wantedā€ feature and try to simplify the full framework providing standard and common patterns.

I hope now is much clear the full context :wink:

I have a question that is some what related. We are designing a PII collection form and would like to get your POV on whether the back button can be removed?
The form is subsequent to a page where to user selected the life insurance policy they would like to go with which has a lot of information such as quotes, carrier and so on.
Iā€™ve always been told that for something as significant as a PII collection page, a back button should remain.

The web form Version 2 is good for the user experience because it has so clear navigation.

If you are unsure about how your user base reacts to it, just do some tests with both button options, and see how they react to the interactions offered. Given you have no time to test with your users, just use a standardized version that worked before and offers both options. You can find standards like those in all design systems, like Googleā€™s Material Design.