The attached image shows a dialog with a save/cancel button bank and a "x" icon to close the dialog. The question I have is this. Should the cancel button even be on the modal if it does not clear/cancel any of the values? I have it in now as a redundant way to close the dialog. Should I just use the "Save" button and rely on the "x" to close, or is the use of the "Cancel" as a redundant close acceptable? My thought was that having a positive action "Save" without a corresponding negative action "Cancel" is a pattern breaker.

Thanks for the feedback.

Save/Cancel Button Question

  • 3
    The cancel button is a bigger target to hit than the [X]. Something which will be appreciated very much by people who are not so deft with a mouse. And not being deft with a mouse is not something reserved for the elderly. Plenty of people around with other causes for not being able to point and shoot all that accurately. Commented Feb 17, 2012 at 19:52
  • Another excellent point. I think I'm going to err on the side of redundancy and keep both metaphors.
    – gstern1994
    Commented Feb 17, 2012 at 19:57
  • 1
    The cancel button is also likely more keyboard accessible
    – DA01
    Commented Feb 17, 2012 at 22:24
  • Fitt's Law Demonstration goo.gl/bsE2v Commented Feb 21, 2012 at 12:43
  • Thanks everyone for all of the feedback, it has been very, very helpful.
    – gstern1994
    Commented Feb 21, 2012 at 20:22

8 Answers 8


Even though [cancel] would not actually clear or cancel any concrete data, in the user's mind it confirms, that none of the values he changed in the dialog will be saved/applied. The [x] should generally always be there, it works as some sort of "way out" for the user, it gives the option to skip the choice and intuitively get out of the situation (for example when he entered the dialog by accident).

The main problem with only [x] and [save] would be, that the user does not know for sure what [x] does (and doesn't do), what his options are. [save] and [cancel] combined, let the user choose exactly what he wants to be done to the changes he made in the dialog; explicit choices make users feel in control of what they're doing.

An [apply] option is also often seen in dialogs, but I would only add an [apply] button, if there are multiple tabs in the dialogwindow.

  • 1
    +1. Precisely, Cancel is explicit about its functionality, while X is not. A user who changed a value and didn't press Save, has no way of knowing whether X will save and close, or just close. Commented Feb 17, 2012 at 20:32

Redundancy isn't always a bad thing. Sometimes, having multiple ways of accomplishing the same task helps accommodate users who are used to different patterns.

In this case, the candidate for redundancy removal is [X] not Cancel because your modal dialog is an editable form, which has a Save button already so the counter-action has to be next to it (as you've mentioned). However, it wouldn't hurt to keep [X] because it doesn't break the flow or add any clutter to the layout.

I would rather focus on the micro-copy & functionality of the Save/Edit buttons: you need to find out whether your users expect Save to act as "save & close" or "save & continue editing". Depending on the results of that inquiry, you may need to either change the labels on the buttons or even add another one to make it equivalent to Apply | OK | Cancel.

  • Excellent points. Would this three button group eliminate the need for the [X] in your view?
    – gstern1994
    Commented Feb 17, 2012 at 19:35
  • 1
    based on my experience, users rarely use the button apply changes when it behaves the way to "save & continue editing" Commented Feb 17, 2012 at 19:44
  • 1
    Not necessarily. [X] is a part of the modal dialog's header so there's empty space (top-right corner) where it can reside without disturbing anyone. In Windows, the design patter is to include [X] in every modal dialog. In OS X, it's inconsistent because some modals slide out of the title bar.
    – dnbrv
    Commented Feb 17, 2012 at 19:48

Cancel and X should do the same thing. There's no point in not closing the dialog when the user presses cancel.


There's a real Windows/Apple thing going on here. Windows typically puts cancel on the right, Apple puts it on the left. Personally, I tend to put the positive action on the right (like moving from one page of results to the next) and the negative action on the left. The 2 buttons are in my view too close together - you need to separate them out, and ideally, if the user has entered anything in this dialog, ask for confirmation, otherwise you run the risk of frustrating the user. And in answer to your main question, you should absolutely have both a cancel and an "x" - many users will not even look to close the window.

  • 1
    IMHO, proximity isn't a huge issue, but the lack of differentiation is. The buttons are visually identical. I'd suggest trying to figure out how to visually differentiate them better.
    – DA01
    Commented Feb 17, 2012 at 22:26
  • Agreed - making the "Save" button the main call to action (maybe through size and colour) would help to resolve this).
    – Peter
    Commented Feb 18, 2012 at 8:11
  • The Visual Weight of Primary and Secondary Action Buttons uxmovement.com/?p=4483 Commented Feb 21, 2012 at 12:44

I'll add my vote for removing the [X] entirely if you can. It should behave like a Cancel, i.e. discarding changes and closing the dialog, but it leaves users to wonder whether it really is the same thing, and if so, why there are two controls that function identically but look different.

The behavior of a button labeled Save is in some ways a more difficult question. In both Windows and Mac OS, we've gotten used to the term "Save" as meaning "save and continue working," and even though we don't see it that often anymore (we're usually hitting Command-S or Ctrl-S), I think that meaning lingers enough to create doubt when we see it as a command button's label.

My rule in a situation like this would be that the button should close the dialog; unless there's a need to preview the changes made in some other window, or what you're doing in the dialog is so lengthy a task that there's real danger in not being able to save it as you go along (in which case you might consider Preview and auto-save, respectively), there's no reason to keep it open.

So I would opt for a label that has come, for better or worse, to stand for "accept and move on": "OK". The OK/Cancel pairing is everywhere, and even though it might feel weird to end a form dialog with "OK," it's the kind of weird that happens when you stare at a word so long it turns into nonsense. Most users won't have to think about what it means, and that's just what you want.

(If for some reason you need a Save that really does mean "save and continue," you want either Save and Close or Apply and Close. "Save and Continue" doesn't pair with "Cancel" because we understand "Cancel" to discard all the changes we made, and it's not clear whether that's all the changes made since we opened the dialog or all the changes made since we last saved.)

  • I like your rationale for this. I need to come up with a consistent pattern to deal with it, we do it differently all over our app. We have an [X] built into a modal, it can't be removed, as it's part of the chrome, so would a Cancel/Close button be useful or redundant or both? Would something like this seem reasonable: Save/Close buttons that give a confirmation message that something was successively saved, and the cancel would just close the modal post haste unless there was unsaved data - this would trigger a message about unsaved data and a choice of saving or canceling the action.
    – gstern1994
    Commented Feb 27, 2012 at 21:21

Case-1: Your "x" close is not relatively at its best position, where it can cause some Perceptual problems, since x aligns with the Title,and what if this in first place needs to get at its usual position above the header blue band, as with aligned along border line of the window. So if we had to move this What next?

Case-2: Let me tell you that Save & Cancel are good to be paired, since when the user approaches the screen, and finds not going to edit any item, its better-off he may choose to Close by using "x" (atleast most preferably 90% would do this fashion) and atleast 10% of people would use "Cancel" - saying "OK, I am not going to edit anything here, let me cancel this action" (This is what my experience helps me to bring the stats here)

Case-3: So Why do we need then the "x", coz it represents same action as in case 2? User will be not be worried to close the modal window with the button "Cancel", and will really not look at the missing piece, since the affordance to Close or Cancel is already provided inside the window. So the 10% would naturally turn 100% since they have the option to chose to close only through "Cancel"

Building on the Case 3, the best way to look at this is, user will edit some item and "Save" or user will edit some item and choose not to save and use "Cancel" or user will look at the screen and perform no action, and would still click "Save" (Here you can chose to Grey off the SAVE button, and making the user to perform the action only if there is some edit on the screen) or perform no action and would say "OK, let me close this" which is otherwise "Cancel". So the inference after the long build-up pointers, is that you may chose not to have "x" and go with pairing of buttons alone. Think about grey-off the SAVE button and make user to chose only if there is an edit linked with it.


There are some great thoughts in this thread so I won't offer my own preferences because I can see reasons for any of the choices you could take. I've also struggled with this same question, it's difficult.

The approach that might be helpful is using evidence to give you your answer. I would test:

  • Current layout - see if users use both options if both are available
  • Only the X - see if users understand what they are doing and if they can find it

  • Only the cancel button - see if users understand what they are doing (this would have to be a cancel + exit interaction or perhaps click cancel then whitespace to exit)

You might find surprising answers depending on the patterns your users are comfortable with.

This would be a relatively simple thing to test with prototyping I think. It's just a matter of changing one screen within your scenarios. I would formulate the tasks so that they don't include the word cancel or exit, and just so happen to require the user to do that action, if that makes sense.


Cancel vs Close: Design to Distinguish the Difference

Long ago, the symbol X meant “this is where the treasure is buried.” In today’s digital interfaces, X no longer marks the spot, but rather functions as a way for users to cancel a process or to dismiss an interim screen. How can one tell for sure whether the X means cancel or close? Sometimes, unfortunately, you can’t.

The main issue lies with the common lack of a text label for the X icon. When an icon represents multiple meanings in similar contexts across different interfaces, icon usability suffers because users cannot rely on any single interpretation.

Avoid Losing Users’ Work To avoid losing users’ work, systems need to determine the user’s intent — cancel or close — and provide clear options.

This goal can be accomplished by one or more of the following:

  1. Asking the user to confirm their intention
  2. Using explicit text labels rather than ambiguous icons
  3. Presenting two distinct buttons:X for closing the view (with the side effect of saving intermediate work) and Cancel for abandoning the process

1. Ask for Confirmation

enter image description hereenter image description here

2. Use Explicit Labels

enter image description here

3. Favor Close & Save

enter image description here

Note that saving intermediate work or maintaining an ongoing process before closing is proactive, but sometimes can be contrary to the user’s intention: If users intend to cancel their selections by clicking the X button, auto applying those selections could be confusing and frustrating. This is why it’s critical to also include a separate Cancel button, to give users an out rather than forcing them to only save and close the view.


While the X icon is ambiguous and can often cause usability problems, it’s unlikely that it will disappear from all interfaces any time soon. Designers should be aware of the multiple meanings of the X icon and disambiguate between close and cancel, as well as provide safeguards such as confirmation dialogs or autosaving to avoid losing any users’ work.

Remember, when in doubt, save, then out.

Refer : NN Group: Cancel vs Close: Design to Distinguish the Difference

  • This does not answer the original question.
    – Ren
    Commented Sep 4, 2019 at 9:51
  • @Ren, It is a perspective of keeping X and Cancel. I explained the way we perceive in a different situation. Better we understand our audience and scenario better we make choices. that what I explained and I believe I answered the question. Because it's not a sum where only one correct answer is there, its user experience which differs one persona to another. Commented Sep 4, 2019 at 13:06

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.