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.
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.
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!
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
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.
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
Sounds like a solid plan! Looking forward to hearing what you find out!
We performed a qualitative test with 8 people.
Each session was focused on two tasks where users have to perform several āgo backā actions:
-
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
-
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.
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.
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
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.
I have different point of solution. I always prefer cancel.