OK and Cancel buttons are omnipresent on the web. Of course, they aren’t always labeled OK and Cancel and they don’t always have the same purpose, but we’ve seen them a million times nonetheless. The combination of the two buttons has maintained its position as a global standard for a very good reason: almost any action you perform in a web application can be canceled. This is seen often in round-trip interactions, in which the user starts an interaction on Page 1, completes it on Page 2, and is then returned to Page 1. It’s also seen in inline interactions, such as changing the title of a Backpack page.

Typically, the set of buttons is displayed as two side-by-side HTML buttons. This is true in many desktop applications as well. Sadly, this design has persisted for years and has found its way into millions of apps. See, the unfortunate side-effect of standards is that people often stop questioning them, and progress almost completely stops regardless of whether the standard is the best solution.

Here’s a typical OK/Cancel button set:

In this case, the object of the interaction is to create or edit a title and then either save or cancel it. Simple enough. So what’s the issue? Well, there are numerous ways to solve any given design problem, and even something as simple as this requires a few decisions.

The first decision to make is about the position of the buttons. It really doesn’t matter much in terms of usability whether the buttons are right-aligned or left-aligned to the field above it, but I generally stick to the left side for a few reasons. First, left-alignment keeps everything flush to the left edge, forming a nice, straight line from the top of the form to the bottom. Second - and this is simply an aesthetic choice - it seems to create a visual “end” to the form. As you complete each field, you move steadily downwards, and placing the action buttons at the tail end of it seems to anchor the form. But that’s just me. The most important reason will be explained in a moment.

The second decision to make is how to label the buttons. Sure, using the standard OK and Cancel requires less effort on a case-by-case basis, because you can simply label them without really thinking about it and move on, but are these terms really helpful? “OK” will work fine in a lot of cases, but more meaningful button labels can go a long way towards setting a user’s expectations about the result of clicking the button.

What does clicking OK do in this example? It probably saves the title. But elsewhere in the application, saving a setting might return the user to the page where he started the interaction, such as a Profile page. In that case, simply clicking OK doesn’t set a clear expectation. There, we should use something like, “Save and return to profile”. And since that’s true, we should maintain consistency and use meaningful button labels everywhere in the application.

On a more basic level, it’s simply more polite for us to set clear expectations regardless of what the user is doing. It makes things more understandable for them, and it makes us look good as a result. Do you need more reasons than that?

Despite all this long-winded logic, labeling the button in a meaningful way is really no big deal.

All we really need to do is change the label from OK to “Save title”. Rather painless.

The final thing to think about here is the thing that goes unchallenged by designers most frequently. It’s the fact that equal weight is often given to both buttons, the two of which trigger remarkably different results. I can understand why this started. Two options equates to two buttons. But this is not what we want to do. Instead of thinking about the number of options, think about the most likely option.

The most likely option for users who have decided to create or edit this title is to save the changes. The less likely option is to cancel the changes. But by giving both buttons equal amounts of visual importance, users have to actually read the labels - on both buttons - to decide which one to click.

Applying Fitts’ Law, which dictates that the time it takes to hit a target is a function of the distance to the target and the size of the target, the ideal solution is to take some of the focus away from the Cancel option by turning it into a text link.

(UPDATED: I changed the link color to black in this screenshot and removed the underline. Those who left comments here are right - a standard blue, underlined link stands out too much. Thanks for your contributions.)

This way, the “Save title” button is prominent and easier to hit with the mouse, while the Cancel link is less prominent and slightly less easy to hit with the mouse. Is it any more difficult to see both buttons? No. But it’s slightly more difficult now to click the wrong one. Your eye is drawn to the large button. And it’s easy to recognize, subconsciously, that the large button is the probably the one you want to click.

This, incidentally, is also why I prefer to keep the buttons left-aligned. It simply looks better to have that large HTML button aligned to the left edge of the field above it than it would to align the Cancel link to the right edge.

So why is it so important to keep the button on the left and the text link on the right? Because any user who uses the Tab key to move through form fields will reach the “Save title” button first, again putting focus on the most likely choice while simultaneously taking focus away from the less likely choice.

UPDATE: Jakob Nielsen has posted an Alertbox article called “Command links” that provides guidelines for when to use text links to trigger commands. His recommendations are very much in line with the example I’ve offered in this post. He recommends using command links for:

Posted by Robert on January 5th, 2007