Jakob Nielsen's Alertbox, May 27, 2008:

OK–Cancel or Cancel–OK?

Summary:
Should the OK button come before or after the Cancel button? Following platform conventions is more important than suboptimizing an individual dialog box.

We get countless questions about small details in UI design that don't matter much to the overall user experience. One classic is the order of buttons in dialog boxes:

• OK/Cancel
• Cancel/OK

Both are reasonable choices, and people can argue for hours about their preferences:

• Listing OK first supports the natural reading order in English and other languages that read left-to-right. Many other button sets have a natural progression (say, Yes/No or Previous/Next). You should always list these so that the reading order matches the logical order — in this case, OK/Cancel. Further, assuming users need OK much more frequently than Cancel, it's better to place this option first so that keyboard-driven users who tab to the buttons can get to their preferred choice with one less keystroke.
• Listing OK last improves the flow, because the dialog box "ends" with its conclusion. Also, as with Previous/Next, you could argue that OK is the choice that moves the user forward, whereas Cancel moves the user back. Thus, OK should be in the same location as Next: on the right.

In cases like this, it often doesn't matter what you do. Either choice has good arguments in its favor, and no choice is likely to cause usability catastrophes. It might save some users 0.1 seconds if you pick the "right" choice for certain circumstances, but it's simply not worth it to conduct sufficiently elaborate research to find out what that choice is. Better to spend your usability resources on those things that can change your key performance indicators by 83% or more.

So, to make this specific choice — as well as many other small choices in application design — it's best to follow the platform GUI standard. Applying consistent design that follows user expectations saves people much more time (and many more mistakes) than doing something that might be a tiny bit more optimal for your application, but introduces an inconsistency.

Inconsistency Costs More Time than It Saves

Deviate from the standard, and you'll easily cost users several minutes — or possibly hours — as they overlook or misuse UI elements. The time people spend pondering inconsistencies typically sums to much more than the small savings you'll hypothetically derive from a specialized design.

Sadly, the Windows Vista User Experience Guidelines differ from the Apple Human Interface Guidelines when it comes to the sequence of OK/Cancel buttons:

• Windows puts OK first
• Apple puts OK last

If you're designing a desktop application for one of these two personal computer platforms, your choice is easy: Do what the platform owner tells you to do.

Dialog Buttons for Web-Based Apps

If you're designing a Web-based application, the decision is harder, but you should probably go with the platform preferred by most of your users. Your server logs will show you the percentage of Windows vs. Mac users for your specific website or intranet. Of course, Windows generally has many more users, so if you can't be bothered to check the logs, then the guideline that will apply to most situations is:

• OK first, Cancel last, as in this screenshot from Office 2007:

The screenshot illustrates two additional guidelines for dialog box buttons:

• It's often better to name a button to explain what it does than to use a generic label (like "OK"). An explicit label serves as "just-in-time help," giving users more confidence in selecting the correct action.
• Make the most commonly selected button the default and highlight it (except if its action is particularly dangerous; in those cases, you want users to explicitly select the button rather than accidentally activating it by hitting Enter).

Learn More

Two-day seminar on Application Design at the Usability Week 2009 conference in Washington DC, San Francisco, London, and Sydney.