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.

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.

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 ?

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.

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.

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.

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.

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.

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.

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.

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.

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

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.