Action: Cancelling

Author: Kevin Hatchoua | Last edit: March 21, 2023 | Design type: Alerting | Product area: Hybrid Cloud Console

Should you show a confirmation modal?

It is not required that you show one. The decision is up to the designer’s discretion, and you should base that decision on the circumstance.

What is required is to use a confirmation modal for a cancellation, and NOT a toast

If it is a task they do often, don’t bother them with a confirmation.

This seems to be very personal, some users love them, and some users hate them. 

When to show a cancellation modal | Things to consider?

Note that these are not hard guidelines. They are just possible suggestions to help you make a decision. At the end of the day, this is very context specific.

1. You could opt to give the user a confirmation dialog depending on how much information they have inputted:
   1. Example: let’s say you have a wizard with 40 fields. You could make it so that if they have only filled out 5 fields or less, they do not get a cancellation modal when they press cancel. On the other hand, if they have filled out more than 5 fields, they would get a cancellation modal.
2. You could opt-to not give the user a confirmation dialog if you think it would be very unnecessary
   1. Example: If a modal is only made up of 3 fields, it would not result in much loss to the user and therefore, it may be unnecessary to add the annoyance of having them confirm the cancellation.
3. If a user has not entered any data, do not give them a confirmation dialog since no data will be lost. 
4. The level of destructiveness will determine how severe the confirmation is. 
   1. If the level of destruction is not great (this will be most cases, ie: they’re not losing something already created in the system) use a blue primary button
   2. If the level of destruction is quite great and causes greater harm than the user having to re-input all the data, use a red destructive button
5. [Ability to offer to undo (in a toast) is great but is very back-end dependent - needs to be engineered to support this early on. Feasibility of this will vary.]

Confirmation modal design

Header: “Exit ____creation?” OR something else if this doesn’t fit your use case for cancellation. Your header must be phrased as a question that will be answered by the button choices. It is important that you do not use words like “modal” or “wizard” as these may not be familiar terms to the user.

Icon: Add a warning icon to show more emphasis 

Body: “All inputs will be discarded.” Can edit this to fit your use case. The idea is to keep it straightforward.

Buttons: The button should answer the question posed in the header. The options should usually be “Exit”, or “Stay”, unless that does not fit your use case. 

• The action that confirms following through should be the primary action:
  • Default to using a primary (blue) button here
    • Reasoning: The greatest consequence of canceling the creation of something is probably the annoyance of the user having to recreate it from scratch. It will not be deleting something already created, and therefore should not cause a big impact.
  • However,  you can use a danger button if the action is truly detrimental

The actions that cancel the initial action should be a link button as shown below

Examples of confirmation modal in use

Example 1

1. User is setting up their cost model in a 5-step wizard
2. The X out of it or click on the Cancel button before they are done completing it, which would mean losing all the already inputted data
3. The Wizard screen would get replaced by this modal (to avoid a modal-on-modal situation) that prompts the user to confirm that they actually want to quit the wizard and lose all their work
4. “Yes, I want to exit” is the primary button because that is the action they wanted to take in the first place
5. “No, I want to continue” is a link button because it is NOT the action they wanted to take in the first place, and would bring them back to the wizard, negating the initial action.

Example 2

1. The user is creating a group in User access and has inputted some data in the wizard flow
2. The user decides to either X out of the wizard, or cancel the wizard creation, which would mean losing all inputted data
3. The Wizard screen would get replaced by this modal (to avoid a modal-on-modal situation) that prompts the user to confirm that they actually want to quit the wizard and lose all their work
4. “Yes, I want to exit” is the primary button because that is the action they wanted to take in the first place
5. “No, I want to continue” is a link button because it is NOT the action they wanted to take in the first place, and would bring them back to the wizard, negating the initial action.