I'm working on a project where there's a CRUD table, but the editing takes place in an individual page. In this editing page, if the user presses the cancel button, a modal pops up asking for confirmation before redirecting the user back to the CRUD table.

enter image description here

There's also a settings page where it's just a single form. In this case the cancel button works more like reset, where it clears the form instead since there's nowhere to return to.

enter image description here

Is it ok to have two behaviors for the same button?
Or should I just remove the latter's cancel button entirely?

I read that it's best not to have a reset button in case users lose information unwillingly, but would it be weird if some pages only had a save button and no cancel, while some have both?

  • Why do you need a 'Cancel' (reset) button in the Settings Page?
    – intnnn
    Commented Mar 30, 2022 at 7:50
  • 2
    If you want to place different behaviors on the buttons then you definitely need to change the text in those cases too. Otherwise you will confuse the hell out of your users. Just call it "Clear Form"
    – Big_Chair
    Commented Mar 30, 2022 at 8:29
  • @Big_Chair Yes I was worried about that too, but would the users see a Clear Form or Reset button and expect it to be in the edit page as well?
    – Vicky
    Commented Apr 1, 2022 at 1:29

5 Answers 5


It's not a good practice to have different behaviours for actions that look similar to the user.

"Cancel" is a way for a user to "Exit" a process or action without making changes.

So your first application of the Cancel button is correct.

If your intended behaviour is to clear or reset a form, you can tell your users exactly that.

You can name the buttons "Clear Form" or "Reset Form".


I see two things here that I think can be improved.

  1. You don't need an "edit" button in the rows of your table. I think it's a better flow if you direct your user to a detail page first, and have them there decide to go an edit the contents. So, have them be able to click on the row, and navigate to the resource's detail page.
  2. Even if you prefer to have an "edit" shortcut (which it basically is, as you are going directly into edit mode and skip the view version of the detail page), it should be a link and not a button. You are not applying an "edit" action directly on the resource, but are merely navigating to a new page where you can perform the edit action(s).
  3. There, once in edit mode, the "Save" (or "Update", as you are updating the resource, REST-ful speaking) is the actual action you're applying. So that should indeed be a button. The "cancel" however is not the secondary action; it is a navigation back to the previous state of your UI, hence why it should be a link.
  4. Alignment-wise there are several opinions. I just happen to prefer the right-aligned for small views.

enter image description here

  • 1
    Wow thanks for pointing out the the use of buttons and links! The table actually also has a Delete button next to Edit though, so maybe it's better if Edit was also a button to make Delete look less prominent? As for the alignment issue, the picture I made is just a general idea, the real page is really long so I placed it on the left-hand side and didn't change it for the reference.
    – Vicky
    Commented Apr 1, 2022 at 1:36
  • 1
    @Vicky I would also refrain from placing a "delete" button directly in the rows of the table. Any delete action should be done from the detail page imo. In any way, delete in the row should then also not be a button, but a link. Unless you immediately want to destroy the resource directly from the table (dangerous destructive action!).
    – Kriem
    Commented Apr 1, 2022 at 9:26
  • But delete would open a confirmation modal instead of directing to another page, which means it should be a button right? And I agree with deleting from the detail page, I should probably change that up, thanks!
    – Vicky
    Commented Apr 13, 2022 at 1:54

Is it ok to have two behaviors for the same button? Or should I just remove the latter's cancel button entirely?

When you have a critical situation (data loss, delete something, update and important information), the button will have a extra validation.

It's prevent usability errors, but you can do a usability test, to see how your users are affected with this.

References: https://www.nngroup.com/articles/user-mistakes/


I do think it's confusing that the cancel button has different behaviours here.

'Cancel' works on the edit page as a fairly well-recognised way of closing a modal or going back.

'Cancel' on the settings page has hidden functionality, where you empty the inputs. Consider whether there are other ways to offer 'clear' functionality, whether it's a 'Clear all' button or a cross icon (button) in the input on the right-hand side.

  • In this case if we opt to use a Clear or Reset button to handle the situation, would it require the edit page to have a similar button as well for uniformity?
    – Vicky
    Commented Apr 1, 2022 at 1:31

Is it ok to have two behaviors for the same button?

No. I think it would be better to rename the [Cancel] button on the settings page to what it's actually doing: [Reset]

If you'd like for users to be able to discard the changes for whatever reason - clicking Reset, or typing something they didn't intend, add a third button [Discard Changes] to the settings page.

The settings page might look something like this:

Settings Page
... contents
[Save Changes] [Discard Changes] [Reset]

From my understanding of your question, I think the above options would be the most useful. Hope that helps! If I misunderstood something, please let me know!

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.