It is one of the most basic heuristics for interaction design to support user control and freedom by allowing users an "emergency exit" out of any situation they may have entered. Undo was truly one of the greatest advances in usability.

The basic rule says to support undo; it doesn't say how. More specific rules are needed for different types of user interfaces:

  • In window-based GUI applications, it is standard to have a Cancel button that closes any dialog box and discards any changes the user may have made within that dialog box. A great way to support exploratory learning. Compare with older systems where you were trapped if you ever activated the wrong command.
  • In editing systems it is usual to have an Undo command that makes the document revert to the state before the user's most recent changes. Sometimes, multi-level undo and redo is supported: this can be very useful but confusing.

The Reset and Cancel buttons are the Web's attempt at mirroring these features, but users usually prefer to use the Back button instead when they want to escape from an undesired state.

Reset: Don't Use

The Web would be a happier place if virtually all Reset buttons were removed. This button almost never helps users, but often hurts them.

Reset clears away the user's input on a Web form, but why would people want to do that? The Web is characterized by frequent movement between pages and users rarely encounter the same form twice. Thus, a Web form is almost always cleared when the user sees it. Even when a user revisits a form in a single session, it is usually faster to edit the old data than to erase it and start over.

The Reset button hurts users in three ways:

  • The worst problem about Reset is that users click the button by mistake when they wanted to click Submit. Bang — all your work is gone!
  • Having two buttons at the bottom of a form clutters up the interface and makes it harder for users to clearly see their next step. Some small amount of wasted time is spent scanning the useless button and deciding which of the two buttons is the correct one.
  • Even when users do want to eliminate some of the data they have entered into a form, it may slow them down to have a dedicated button for doing so, since the extra button means that users have a choice:
    • edit the erroneous fields and replace the old text with the new text
    • click Reset and type the new text into nice clean fields
    The extra choice requires extra thinking, and the time saved by using an optimal interaction technique is often smaller than the time wasted on having to think instead of just moving ahead with a single interaction technique that is always used. It takes at least one second and often two seconds to decide between two possible interaction techniques which is why it is usually better not to offer users a choice. (A second may not seem like much, but it translates into about $100 million in lost productivity per year world-wide.)

Make All Form Entries Undoable

To eliminate the Reset button, it becomes necessary to offer users another escape route for erroneous form entries. In the case of text fields or check boxes, the user can always erase the entry and revert to the original state.

Unfortunately, some Web forms use radio buttons and pull-down menus in a non-standard manner and do not offer a neutral choice. A classic design mistake on the Web is to have radio buttons that initially do not have a selection. Often, there is no way for the user to select a "nothing" option, once he or she has selected one of the choices. Always include an explicit radio button for the default choice and always include a selectable menu entry in pull-down menus for the default choice. Otherwise you do trap users. (See also all 13 guidelines for checkboxes and radio buttons.)

Exception: Use Reset for Repeated Form-Filling and for Revert-to-Default

Reset can be useful for forms that satisfy both of the following criteria:

  • the form is filled-in repeatedly by the same user
  • the data to be entered differs significantly from one use of the form to the next

Even if a user were to use a form frequently, the reset button would still not be necessary if the data was mostly the same from one use to the next. In these cases, it would be easier for the user to edit the old data than to erase it and start from scratch.

A Reset button can also be useful in complex dialogs where the user is asked to specify parameters that have good default valules. If the user has wandered far from the defaults during exploration of the parameter space, Reset can offer a quick way home to safe grounds. (Note that here, Reset doesn't really clear things, as much as it replaces changed values with safer or more normal values.)

Cancel: Use Sparingly

The Web is not an application environment, and it usually doesn't have dialog boxes. Instead, the Web is a navigation environment where users move between pages of information. Since hypertext navigation is the dominant user behavior, users have learned to rely on the Back button for getting out of unpleasant situations. Whenever users arrive at pages they don't want, they slam their mouse directly onto the Back button.

Because Back is such a strong behavior on the Web, it is usually not necessary to offer explicit Cancel buttons. If the user asks for something but doesn't want it, then you can be sure that it's Back button time.

Offer a Cancel button when users may fear that they have committed to something they want to avoid. Having an explicit way to Cancel provides an extra feeling of safety that is not afforded by simply leaving.

Cancel is mainly useful for multi-step dialogs where the user has progressed past one or more pages with actions. At this time, pressing the Back button will not undo these actions and it would be better if the user would click Cancel.

Of course, one cannot rely on having the user click Cancel , even if it is offered, so the back-end logic must be able to handle abandoned multi-step dialogs where the user decided to leave through the use of the Back button. This added complexity is one of the reasons I don't recommend trying to implement advanced applications inside a Web browser. It is better to use another form of Internet-enabled applications.

Remove Button in Shopping Carts

It is necessary to have a special button in shopping carts for removing a product. Users cannot be assumed to understand that they can cancel a purchase by buying zero copies (even though this technique should be supported as well since it does not interfere with users unless they decide to use it on their own initiative).

(See my report on shopping cart usability for additional guidelines on forms design.)

Clarification: When Cancel Is Necessary

Lisa Padol asks:

When you talk about cancel and reset buttons, you do not mean the stop (as in "stop the page from loading") and reset/refresh buttons, correct?

I presume it's not only acceptable, but also required to have a cancel button for things like downloading files?

She is correct in both assumptions. The browser's Stop button is a great example of a technique to increase the user's control of the dialogue. Same for a way to interrupt file transfers or any other actions that take more than a few seconds. Designers must include such features in any applets or other design elements that can take time.