Forms

Killing the Cancel Button on Forms for Good

The Cancel button belongs in many places, but a form is not one of them. Their presence on forms isn’t as common as before because designers are starting to realize how useless and confusing they are. It’s time to put the final nail in the coffin for Cancel buttons on forms for good.

Cancel buttons don’t belong on forms for a couple of reasons. One is that it gives users the opportunity to accidentally click on it when it’s mistaken for the Submit button. Removing the Cancel button completely removes the chances of this mistake happening. A Cancel button may also communicate to users that the Back button doesn’t work on the form page. Of course, the Back button does work, but the Cancel button gives users the impression that the only way out of the form is through the Cancel button.

Most users have a habit of relying on the Back button when they land on a page they want to leave. A form page should not change that consistency because the Back button is what users are most comfortable and familiar with. Form pages should function like any other page on a website, so that users won’t get confused as to why they can’t go back a page.

There’s no room for Cancel buttons on forms, but they do have a rightful place in other situations. There are two situations where Cancel buttons make sense.

The first situation is confirmation windows. Confirmation windows tell users that a process is about to begin. The user is given the choice to go ahead with or cancel the process. A Cancel button here is useful and effective because without one the user has no choice but to go ahead with the process.

The second situation is progress bars. Progress bars display when a process is in progress. While in progress, the user can still cancel the process before it finishes.  A Cancel button here is useful and effective because without one the user has no other way out of the process.

The Cancel button gives users freedom when used appropriately. When they’re not used appropriately, they can give users a sense of confinement. Cancel buttons have no place on forms. For the sake of good form design, it’s time to say goodbye to them once and for all.


Books

design_vetting-below_article

Email Newsletter

Affiliate

Divi WordPress Theme

Toolkits

wireframes-kit
site-flows-kit
user-personas-kit

Article written by anthony

Author and founder of UX Movement. Creating a better digital world for mankind by teaching and evangelizing best practices, standards, and techniques in user experience design.

This Post Has 27 Comments

  1. matt Reply

    I don’t really like confirmation dialogs. Instead of “are you sure(ok/cancel)” I prefer “Foo has been frobbed(undo/ok)”.

    • Devin Reply

      And one better is:
      Foo is about to be frobbled.
      (don’t frobble) (frobble)

    • Gary Reply

      The “undo” depends on what has actually happened. If the user closes the application (or browser) without pressing either button, has the action actually been “done” ?

  2. Foresytz Reply

    This is a generally agreeable practice. A good example is the case of online applications where inadvertently hitting anything other than SUBMIT results in huge frustration. However, I was very grateful for several cancel buttons today while I was managing my Highrise contacts. The changes I entered were done just to test the system. In the early days, edits made to a database were immediately applied without the need for hitting SAVE or SUBMIT. In fact, Apple’s iCalendar still works that way; there is no SAVE anywhere in the application. The presence of a CANCEL button provides assurance to the user that the software isn’t going to apply his edits automatically. Most internet interactivity involves a form, so as long as people and apps are as diverse as they are, each development team will need to assess the relevance of a cancel button. I think subordinating the cancel button to other choices or simply providing a text link would serve well in the cases where one is needed.

  3. Kroc Camen Reply

    Shouldn’t the buttons on the confirmation dialogue say “Yes” / “No”, instead?

    Who in real life asks a question and says “OK / Cancel?”

    • Devin Reply

      Yes and no don’t give much context either. You shouldn’t expect your users to read the dialog. Have them side with an action.

      E.g. (Delete files) is one button and (don’t delete files) is another.

      • Gary Reply

        How about “Abort” and ‘Proceed” ?

        I suppose it is really the “OK” I have problems with. It is a fairly wishy-washy, ambivalent response. It fits more with a “Do you want me to delete this …” rather than a “Do you want to delete this….” Is it the application taking the action or the user ?

      • Jim Danby Reply

        Not in the dialog above. The message asks a question that deserves a Yes or No answer. To use other text on the buttons demands different text in the message.

        • David L Reply

          YES! Yes or No is the proper choice of responses to the question: “Are you sure you want to do that?”

          It’s partly because of blind adherence to consistency in our development tools and libraries that we end up being pushed into OK/Cancel choices for Yes/No questions. I appeal to authors of our software tools and libraries: Please provide the option for Yes or NO. OK?

          I suppose, on the other hand, that we could rephrase our questions as Gary suggests – but that seems less clear than being able to offer Yes/No.

  4. brmore Reply

    I would suggest that you could dispense with “cancel” button in confirmation dialog as well.,.

    The intuitive answers to “are you sure you want to do that” are “yes” and “no” not “ok” and “cancel”

    Or so it seems to me 🙂

  5. Slothbear Reply

    I really like this idea, since I’ve lost plenty of data by pressing the cancel button by accident. But I’m a UX newbie, so I could use a bit more guidance.

    Could you outline the best practices for alternatives to the cancel button on forms? I saw “back button” and “text link” as alternatives mentioned so far. I’m not certain all my users would be comfortable with the back button. A text link like “abandon changes and go home” sounds more explicit — and less likely to be pressed by accident. But that sounds a little awkward too.

    I have a form that allows the user to edit a bunch of rows at a time, and I just added the cancel button yesterday. I’m in a great spot to correct that, once I figure out what correct is.

    • anthony Reply

      Choosing the right labels for your buttons depends on the context of your application, and where users are in their task flow. It doesn’t have to say Cancel, but it is always binary.
      You’re asking users if they want to do X, or not do X.

      A better action button for your tables would probably be Undo, instead of Cancel.

      • Slothbear Reply

        I don’t understand how Undo is a good choice. If the user is editing the list of rows (in the form), then the changes have not yet even applied, so there is nothing top undo. Maybe “don’t change anything!”?

        If it is always a binary choice, then is this article really about How To Relabel Your Cancel Button? I caught a more subtle shift the first time I read the post, but perhaps my UX newness was stretching.

        I hope I’m not annoying — I really want to make my app better.

        • anthony Reply

          You’re actually getting on my nerves a little bit. Just kidding. 😛 Seriously though, If you’re asking if you should include a Cancel button at the bottom of your form, then you’ve already answered that question yourself. The changes have not yet been applied, so what is there to cancel? Just make it easy for them to get back to their previous page. Don’t break the back button and keep the navigation header consistent.

  6. Jerome Gravel-Niquet Reply

    I agree with the general premise of the article.

    However, that ok/cancel example is also an example of bad UX. Buttons on a confirmation dialog should always reflect the action which is going to be accomplished. (ie: Save, Apply, Agree and any action verbs.)

    “Cancel” seems to be the remains of desktop development where you could get stuck somewhere. In browsers the back button or a link in the header to another section usually provides the same functionality.

    Let’s get rid of “Cancel” 🙂

  7. Tommi Reply

    Replied here about modal dialogs.

  8. Joe Reply

    I’m bridging back the reset button on forms. Just in case, ya know, someone wants to start over…

  9. Gordon Reply

    I’ve also seen plenty of modal overlays with both an [x] close button and “Cancel” button in the footer, both of which perform the same function in those cases.

  10. Rebecca Reply

    I understand all the contextual arguments and the flow arguments, but what if I just want to quit filling out the form?

    Do I just abandon the page?

    I ask about abandoning the page because, in a few instances, I have filled out forms, abandoned them, and then returned (can’t remember the reasons now) and been taken back to my place in the form I bailed out of earlier.

    I finally had to cancel the form to make the database drop my information and to let me tour the web site in peace.

    R

  11. Arun Agrawal - Webile Reply

    I am pretty much against the Cancel button on the forms. As suggested, I prefer to rely on the back button to take the user back to the previous screen.

    When situation really demands a Cancel button, I make sure I have colored it Red (or a lighter shade) and the forward action button in a matching shade of green. This adds a visual clue and helps the user pause before pressing the cancel button by mistake.

    Arun

  12. ray Reply

    the back button will refresh the whole page. in some applications, e.g. using ajax, editing occurs in a small area of a page, a cancel button required some time.
    another issue, in most cases, the cancel button is closer to the cursor than the back button

  13. Gonçalo Borrêga Reply

    I agree… we don’t need a cancel button. Even further… we don’t need confirmations. There should just be an easy and fast way to UNDO every action in a system.

  14. Caroline Jarrett Reply

    The problem with these fun, eye-catching rules like “Kill the cancel button” is that it’s so easy to find exceptions (as you did in this piece).

    There’s nothing wrong with a cancel button. It’s just a button.

    There’s everything wrong with putting a cancel button where a user presses it by mistake for another button.

    In fact, the rules for labelling buttons are quite simple:
    1. Label the buttons with what it does.
    2. If the user doesn’t want to do it, don’t have a button for it.

    OK, I realise that these rules aren’t as fun as saying ‘kill the cancel button’. But they do work.

    For a longer version with more explanation, see this article:
    http://www.usabilitynews.com/news/article2949.asp

    • Yosef Springmann Reply

      Can you be a little less prepotent? your article is deep as a saucer.

  15. Paul Reply

    Pedantic moment:
    We should be attentive to our design, and be intuitive, etc.

    You have the first picture as a progress bar, and a second picture of a confirmation.
    The text talks about the first situation being a confirmation and the second a progress bar.

    That’s not intuitive!

  16. Avangelist Reply

    This is a topic I struggle with daily.

    In an application, there are a lot of process that a user interacts with.

    @Rebecca mentioned dropping out of a form only to come back to it later to find the data she entered was still present. This is a good example of the cancel button being required but not for the right reason.

    This is a technical constraint which means we force on the user to reset the stored data. It is a great example of where a technical process is applied which requires the user to make programmatic decisions that don’t necessarily relate to the task they are undertaking.

    On the whole, we rarely use cancel buttons, we just drop out. navigation to another page or another site entirely. At this point, chances are you didn’t want to complete the process. There are arguments for and against providing a ‘where you left off’ solution in this scenarios which reopens the debate.

    It’s always been my feeling that any process which writes / stores data in stages should have a cancel button after the first interaction to ‘undo’ the data written. Otherwise, I just don’t think it is required.

  17. Slavic Reply

    Great article anthony.

    I have even had people tell me that the “cancel” button makes them feel as if there is some risk involved, ie: “do you really want to be doing this”.

    It can be intimidating 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *