Action buttons exists at the bottom of almost every web form. They’re so common that we often doesn’t even reflect on how to actually design them. By gathering information from a few of the great minds in the field of web usability and also from my own experiences, I’ve tried to come up with a set of best practices on how to design them efficiently.

Position

According to Jakob Nielsen, the order of the buttons doesn’t matter that much. Both positions has it’s pros and cons. The important thing is to be consistent and if possible follow platform GUI standards [1].

Outside the web world there are GUI standard. The problem is that they are different on different platforms. On the Windows platform the GUI guidelines state that OK should be positioned to the left and Cancel to the right. On the Apple platform it’s the other way around.

On the Web there really is no standard on how to do this, so we have to try to find out which position is the smartest on our own.

Luke Wroblewski elaborates on this topic in his article Web Application Form Design [2]. His recommendation is to position the Primary action (OK) aligned to the left part of the form and the Secondary action (Cancel) to the right.

He elaborates even further on this topic in the book Web Form Design [3], where he presents the finding from a usability test performed on a form with different designs. What the test showed is that having the Primary action left-aligned and the Secondary action to the right of it makes for the fastest performance.

Robert Hoekman, jr. has also thought a lot about this and presents his thoughts in the book Designing the Moment [4].

He agrees with Luke Wroblewski that the Primary action should be left-aligned with the form. The reason for this is that this forms a nice line for the eye to follow, working it’s way down the form, thereby making it easy to scan. Another reason is that if the user is navigating the form with the tab-key, the Primary action comes before the Secondary action in the tab order.

Labeling the actions

Robert Hoekman, jr. also have some thoughts about the labeling of buttons. Instead of just labeling the buttons OK and Cancel it’s better to label them after what they actually do [4]. If it’s to save a note, then why not label the OK-button “Save note” instead. Jakob Nielsen also recommends using a label that explains what it does instead of just a generic label [1]. By doing this the user is more confident using the form since he knows what to expect when he pushes that button.

Visual distinction

One other thing Robert Hoekman, jr. discusses is to visually distinguish the actions making it easier for the user to pick the right one.

Luke Wroblewski also concludes that making the Primary action stand out more than the Secondary action is a good thing. In the findings of the usability test, he finds that it takes the user a little more time to complete the form if the Primary and Secondary action has a different design. But on the other hand it makes the user more confident and less prone to choose the wrong one. He suggest making the buttons in different colors or making the Secondary action a plain link.

A simple way to visually distinguish the two that I sometimes do, is to use a bold font weight on the Primary action and a normal font weight on the Secondary.

Robert Hoekman, jr. recommends using a plain link for the Secondary action [4]. He’s arguments for this is that it makes it clear which one is the most prominent. But it also applies to Fitt’s Law, which suggest that the distance and the size of a target determines how long it takes to reach it and click it. The bigger the target the faster. The Primary action should therefor be bigger than the Secondary action.

In user tests that I’ve conducted I’ve found that some users can get a little confused by a plain link “acting as a button”. I think that this might be because of never having encountered it in a form before. But as this practice gets more common in both web- and windows applications, I think that this is probably not a persistent problem.

The Reset button

The Reset button is used to reset an entire form. It was pretty common in the early days of the web but is rarely seen nowadays. Nevertheless I thought I would say a few words about this button too since when it appears in a form, it’s usually paired with the Primary action.

In most situations it’s best not to use this button at all. All to often users click the Reset button by mistake thereby deleting everything they’ve entered. (I did it as I wrote in Confusing Northface contact form) And seriously, how often do you want to reset an entire form, and if you do, how hard is it?

The risk with this button is simply to big compared to the possible benefit of it. Plus in most cases it just adds more clutter to the form.

Or as Jakob Nielsen put it in his alertbox column Reset and Cancel Buttons [5]:

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

Possibly the only time when a Reset button is called for, is when a form is used repeatedly by the same user and the information entered differs from each use.

Luke Wroblewski has an idea about the Reset button [3]. He thinks that if you provide one you should also provide an undo for it. By changing the Reset button into an Undo after being clicked the user can restore the form. This means that you have to temporarily store the form data, but that’s a small price to pay for the convenience of the user.

Best practices

Taking all of the opinions above in consideration, plus my own experience in using and designing web forms, I’ve come up with these best practices.

• Position the Primary action to the left

  Having the buttons aligned with the left side of the form makes a clear path for the eye to follow. By putting the Primary action to the left of the Secondary action it’s also positioned first in the tab order.

• Label the actions in a natural language

  By describing what the action actually does, the user feels more comfortable using it since he know what to expect.

• Make the Primary action stand out

  This makes it easier for the user to choose the option that’s most likely without making it harder to find the other option.

• (Almost) Never use a Reset button

  Reset buttons often hurts user more than it helps them. The only time it’s called for is in a form that the same user uses over and over again with different input. If you use a Reset, also try to provide an undo function.

Do you agree with my conclusions or do you have a different opinion about this? Please share!

References

1. OK–Cancel or Cancel–OK?, Jakob Nielsen 2008
2. Web Application Form Design
3. Web Form Design, Chapter 6, Luke Wroblewski 2008
4. Designing the Moment, Chapter 13, Robert Hoekman, jr. 2008
5. Reset and Cancel Buttons, Jakob Nielsen 2000

Translations

This article is also available in:

• Chinese: web??????? (Translation by 2003)