Killing the Cancel Button on Forms for Good

by on 10/09/10 at 12:34 am

The Cancel button belongs in many places, but a form is not one of them. Their presence on forms isn’t as strong 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.

Killing the Cancel Button on Forms for Good

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.


Killing the Cancel Button on Forms for Good Killing the Cancel Button on Forms for Good

Author and editor-in-chief of UX Movement. Loves great web experiences and fights for the user.

27 Responses to “Killing the Cancel Button on Forms for Good”

  1. matt

    Oct 9th, 2010

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

    • Devin

      Oct 9th, 2010

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

    • Gary

      Oct 14th, 2010

      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

    Oct 9th, 2010

    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

    Oct 9th, 2010

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

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

    • Devin

      Oct 9th, 2010

      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

        Oct 14th, 2010

        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

        Oct 15th, 2010

        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

          Feb 7th, 2011

          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

    Oct 9th, 2010

    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

    Oct 9th, 2010

    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

      Oct 11th, 2010

      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

        Oct 11th, 2010

        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

          Oct 11th, 2010

          You’re actually getting on my nerves a little bit. Just kidding. :P 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

    Oct 9th, 2010

    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

    Oct 9th, 2010

    Replied here about modal dialogs.

  8. Joe

    Oct 9th, 2010

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

  9. Gordon

    Oct 11th, 2010

    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

    Oct 12th, 2010

    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

    Oct 14th, 2010

    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

    Oct 15th, 2010

    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

    Oct 15th, 2010

    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

    Oct 20th, 2010

    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

      Oct 28th, 2010

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

  15. Paul

    Dec 7th, 2010

    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

    Jan 5th, 2011

    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

    Jan 7th, 2011

    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 Comment