download bmml source – Wireframes created with Balsamiq Mockups

I'm making a Windows desktop application. It's "too hard" to build in an Undo action.

I have a task that opens in a modal window, it's a task that may take the user a while to do, so I want to prompt them to save changes if they hit cancel by accident.

If they press cancel, the confirm dialog will say something like "Changes have been made, are you sure you want to discard these changes?"

My question is what buttons should there be (on the original task window and the confirm)? Save/Cancel? The user clicked the cancel button, then sees the confirm dialog, so they may press cancel again because that's what they want to do, but that would cancel the confirm dialog, not the original task. Also, would I prompt to save from the cancel?

[ Cancel ] > [ Don't Save ][ Save ][ Cancel ]

That doesn't seem right, because to continue with their original decision to cancel, they'll have to [ Cancel ] > [ Don't Save ].

  • Can you use the built in wireframing tool to add a visual of this problem in context? It'd be much easier to assess, and you'll get better feedback
    – dennislees
    Commented May 9, 2016 at 20:00
  • Nice wireframes : ) What's the task they're doing? Can it be referred to in in a single word? like "Editing"?
    – dennislees
    Commented May 9, 2016 at 20:10
  • "Its too hard to build in an undo" I hear this a lot from my dev teams, but I point out that if you want a great user experience don't expect things to be easy to build, so put in the hard work and your users will love you for it.
    – SteveD
    Commented May 10, 2016 at 9:53

4 Answers 4


Use more specific language in your CTAs

Perhaps you've got a style guide that might prohibit this, but part of the existing problem is that the microcopy is typically generic.

  1. Leave the buttons in the task modal as [Save] and [Cancel].

  2. Restrict so that it's only possible to save from the task modal.

  3. Use more natural language instructions in the Confirm Dialog


download bmml source – Wireframes created with Balsamiq Mockups


There's a few other things you can do to help here.

  1. Don't put your cancel and save buttons together, that way a user is less likely to get to the dialog without meaning to. I'd put cancel over to the left out of the way, or even remove and allow the dialog close button to take that role.

  2. Autosave in the background, resulting in a 'draft' status record that they can come back to later. If you can save a completed task, then you can save a partially completed task.

  3. Or, similar to 2, give them a 'save progress so far' button, leaving them the option to come back later.

  4. You could choose a different paradigm altogether for cancel and discard, one that doesn't involve dialogs, perhaps more like an iPhone delete process or some other thing that makes the user have to think a little bit more than just clicking buttons.

Personally, I think in 2016, the progressive save, manual and automatic, should be the default position of any interface build that captures info more complicated than a few words. Users should not lose work these days. With this sort of thing it's less important to try and catch all mistakes with dialog buttons.

It may be that Windows paradigms are expected but just because that's how things have always been doesn't mean that's how to do them - building things in the best way to help your users complete a task regardless of expected paradigm is the best way to do things.

It seems the goal of question is to stop the user from losing work and that isn't going to be optimally achieved whatever combination or words and buttons you choose. People will struggle with button position, automatic responses to pop-ups and confusion over wording so it's better to try to catch them from ever falling into this trap.

  • Re #1. I've thought about this and I do like it, but it goes against the familiar (to my users) Windows UI
    – alanj
    Commented May 9, 2016 at 20:46
  • @alanj That maybe the case, but it's also quite possibly the case that people are sick of hitting cancel by mistake - the old-school Windows UI, which this resembles somewhat, is not renowned for exquisitely tailored UX, it's patterns shouldn't be copied just because that's how it's done, they should copied or discarded based on what helps the user get the task done.
    – Toni Leigh
    Commented May 9, 2016 at 20:51

If you are going to ask your user a question, you should ensure the call to actions answer that question, e.g. Treat this like a conversation:

"Are you sure you want to discard changes?"

  • Yes, I want to discard changes
  • No, I made a mistake and want to continue working

This can be simplified to:

  • Yes
  • No

Clicking Yes triggers the Discard feature and closes the Confirm dialog.

Clicking No cancels the Discard feature and returns you to the form to continue working.


Simplify the modal wording:

"Discard the changes you made?"

Make the buttons simpler as well "Yes, Discard" and "Cancel".

  • Most users don't read stuff, I'm concerned that they'll want to cancel, click [cancel] on the main window, then see [cancel] again in the confirm, and click it in error because that would close that confirm dialog.
    – alanj
    Commented May 9, 2016 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.