Cancel button vs back navigation

usability

#1

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


#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.


#3

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.


#4

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


#5

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:


#6

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:


#7

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:


#8

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…


#9

Ah. In that case I think it makes sense.
I was thinking you meant ‘cancel this current step’ rather than ‘cancel this entire process’.


#10

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.


#11

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?


#12

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


#13

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


#14

I will let you know :slight_smile:


Page header as a framework component
#15

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.


#16

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.


#17

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: