UX writing: an effective ‘Cancel’ dialog confirmation on Web

Photo by Scott Graham on Unsplash

In this article I want to approach a specific issue that arises when users are going through a certain flow or task on a Web app and for some reason they want to abandon it and have to click a ‘Cancel’ button.

Standard footer structure seen on Web apps

A common practice is to display a confirmation dialog afterwards in order to be sure users actually want to proceed with that cancelation. And that’s exactly when the issue might occur since the dialog also needs a way to be canceled, and might also have a ‘Cancel’ button.

Standard confirmation dialog structure seen on Web apps

This ‘Cancel’ button conflict can be confusing for some users and it was something we had to figure out within the design team at my company. So that was the main goal behind this article, to provide more clarity on how to write an effective ‘Cancel’ confirmation dialog.

Three scenarios

To get started I did some research within our own product (a banking app) to identify the different places and flows where we were facing this problem. After that, it was possible to map all the examples to three main scenarios:

1. During a creation flow

A user, let’s call him John, is going through a creation flow (for example, creating a new budget to manage his expenses) and after entering some information, he decides to abandon the flow by clicking ‘Cancel’. Then the confirmation dialog appears.

2. During an editing flow

Following up on scenario number 1, let’s imagine that John actually created a new budget. After a while, he comes back to the app to edit that budget (for example, to adjust the budget amount). While editing that budget he decides to abandon the flow by clicking ‘Cancel’. Then the confirmation dialog appears.

3. During a ‘Cancel’ action flow

On a different context, John interacts with a specific action in the app designed to ‘Cancel’ some previously executed task or submitted information (for example, canceling a scheduled payment). Then the confirmation dialog appears.

Broader research

Next step was to do some external research and see how other products out there were handling similar scenarios and if there were any recommendations and good practices about this topic.

All the research including screenshots and links to different articles

Without getting into much detail here, I can highlight that Shopify (and their design system Polaris) was an extremely good reference on how to approach this problem. They have a whole section on their website dedicated to content writing, and a sub-section that provides specific best practices for writing confirmation messages. Another interesting resource that provided great insights was an article I found on Invision app blog about Microcopy for destructive actions.

Guideline

After bringing all the research collected in the previous two steps for discussion amongst the design team, the outcome was an agreement on a generic guideline for ‘Cancel’ confirmation dialogs that would help bring more consistency to our product while improving the end user experience. Eventually this guideline would be included in our own internal design system patterns library.

Structure breakdown for the confirmation modal

1. Question — start with the main action (discarding information or canceling something) plus the context of what it’s referring to.
2. Consequence — no more questions, just tell user’s what happens if they proceed. Most probably they will lose all the information entered.
3. Way out — use an action that resembles the exact opposite of the primary action button. According to the context, some common options can be: Dismiss, Not now, Keep it, Continue. Obviously, we’re trying to avoid using ‘Cancel’ here.
4. Decision — should match the action used in the question title, including what it’s referring to. In this case, Discard or Cancel.

Final examples

Now coming back to the three main scenarios I’ve identified before, let’s design more clear and user-friendly confirmation dialogs for each of them using the guideline as reference.

1. John is canceling the creation of a new budget to manage his expenses.

1. Question —straightforward question here using ‘Discard’ as the action and highlighting what the user is discarding.
2. Description — the user can probably assume he will lose all the information entered so far but we can still use the description as a chance to be 100% clear about that if he’s willing to read it.
3. Way out —we’re looking for an action that conveys the total opposite of ‘Discard’. In this case ‘Keep it’ makes sense, or even ‘Keep budget’ if we want to take it further.
4. Decision — again we reiterate the main action in this context, keeping it consistent in both modal heading and primary button. The main goal here is that if the user doesn’t read anything else, he can still understand the action consequence. If we just used ‘Discard’ that might not be the case.

2. John is canceling the editing of his previously created budget.

1. Question — the only difference here is that the user is discarding changes to a previously created budget instead of a new one.
2. Description — same as the previous description with a small tweak to be clear that the user will only lose the changes made.
3. Way out —similar to the previous example but reiterating the editing context.
4. Decision — in this case I opted to not use the budget context in the button because it would make it unusually long (‘Discard budget changes’). I think the consequence still comes across without it.

3. John is canceling a previously created scheduled payment.

1. Question — in this context the ‘Discard’ action its not the best fit anymore since the user is actually canceling something he had created before. For example, imagine a list of scheduled or recurring payments where the user has a ‘Cancel’ button for each of them.
2. Description — same as the previous examples but highlighting the irreversible nature of this action.
3. Way out — just showing here another alternative for the secondary action. I think the ‘Keep it’ action we used before would be a valid option too. Maybe even better for the sake of consistency across the different scenarios.
4. Decision — nothing new here, same as the first example. Replacing ‘Discard’ with the appropriate action.

That’s it. Hopefully this guideline can be helpful in your own design work when dealing with confirmation modals. I’m sure there’s still ways to improve on it or details that I might’ve overlooked so feel free to comment and let me know your thoughts. Thanks for reading, appreciate your time.