Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right
by anthony on 05/25/11 at 11:30 pm
A question designers often wonder when designing dialog boxes is where to place their ‘Ok’ and ‘Cancel’ buttons. The ‘Ok’ button is the primary button that completes the action the user initiated. The ‘Cancel’ button is the secondary button that takes users back to their original screen without completing the action. Based on their functions, what is the best order to place them? Should the ‘Ok’ button come before the ‘Cancel’ button or after?
Platform consistency is not good enough
Many have referred to following platform conventions as the answer. While this might seem like a solution to the problem, it really isn’t. It doesn’t answer which placement works better for users and why. The suggestion to follow platform conventions for the sake of consistency is simply not good enough and leaves designers empty-handed.
“Consistency” is a popular word used among designers. It’s also a popular excuse to use to not think deeply about the design problems users face. What’s the benefit of following a design convention, if one doesn’t know why it exists, or if it’s right for users in the first place? What if a certain design convention is harmful to users? Should designers blindly follow it for the sake of consistency? Should bad design practices and lack of design understanding persist because designers want to resort to platform design consistency as the answer to every problem?
There are certain platform design conventions that are widely used today because they work for users. But the point here is that platform design consistency should never satisfy a designer as the sole reason to do something. A true designer needs to understand the problem at a deeper level. And understanding the reasons why you should design your user interface one way, as opposed to another way is key.
Visual weight & labels matter, but so does placement
One could argue that making your action buttons prominent by giving it more visual weight and a clear and distinct label is more important than its placement. While the visual weight and labels of your action buttons are an important design aspect to consider, it’s not the only aspect.
To only focus on one design aspect and not the others is an act of a careless designer. A meticulous designer would think about how every design aspect affects the user. And it’s how primary and secondary actions are placed that is hardest for designers to figure out. That’s why the ‘Ok’/’Cancel’ button debate is such a popular one among designers.
Why ‘Ok’ Buttons work best on the right
When you get past the platform conventions argument, you’ll start to think about which placement truly works best for users. You might say to yourself that user testing is the only way to figure this out. If you’re an inexperienced designer who doesn’t trust your own judgment, then user testing is probably your best bet. But if you’re a knowledgeable and experienced designer who can think about problems from the user’s perspective, then you can solve this problem through design analysis.
Less visual fixations
To analyze this design problem, it’s necessary to see if the common assumptions designers make actually hold up. Some designers believe that putting the primary action on the left side before the secondary action is better for users because it’s closer and, therefore, takes less time to click. This makes sense, but you cannot ignore the fact that users will look at all of their options before they choose which action to take. This means that most users won’t blindly click the primary action button without also looking at the secondary action button next to it. They’ll first see the primary action on the left and then look at the secondary action on the right. Then they’ll move their eyes back to the primary action to click it. This creates a total of three visual fixations in multiple directions.
With the ‘Ok’ button on the left, the visual fixations are more and flow in multiple directions.
With the ‘Ok’ button on the right, the visual fixations are less and flow in one direction.
Compare that with the primary action placed on the right of the dialog box and the secondary action placed on the left. Users start with their eyes on the secondary action, and move their eyes to the primary action to click the button. This creates a total of two visual fixations in one direction, giving users a faster visual flow. Users fixate on each button only once and end on the primary action button. Putting the primary action left might make it easier for users to reach, but when you look at speed in terms of the user’s mental processes and visual fixations, placing the primary action on the right of a dialog box is actually faster.
Maps to the expected button functions
When users click secondary action buttons, they expect the application to do nothing and take them back to their original screen. Thus, ‘Cancel’ buttons function like ‘Back’ buttons. When users click primary action buttons, they expect the application to do the action the button says, and take them forward to the next screen. Thus, ‘Ok’ buttons function like ‘Next’ buttons. Placing the secondary action button on the left and the primary action button on the right maps to the ‘Back’ and ‘Next’ button functions the user can expect.
It’s similar to how pagination buttons are placed. The button that takes users to the next page is on the right, and the button that takes users back to their earlier page is on the left. This button placement works because it maps to the user’s left-to-right reading and navigating direction, where right is the direction to progress and left is the direction to regress.
‘Ok’ progresses users forward to the next screen and ‘Cancel’ regresses users back to their original screen.
‘Ok’ and ‘Cancel’ buttons in dialog boxes should follow a similar interaction pattern because they function like pagination buttons. Not only that, but the left and right directional pattern is what users are used to in the western world. Placing your primary action on the right and secondary action on the left will make your dialog box buttons easier and more intuitive for users to understand.
Gives users a more efficient task flow
A button placed in the bottom right corner of a dialog box is easier for users to click because it follows the Gutenberg diagram. In the Gutenberg diagram, the bottom right area is the terminal area. This is the area where the user’s eyes end up when they finish scanning. Placing your button in this area allows users to see the primary action they need to take last. This not only improves the visual flow, but the task flow as well. Users won’t skip past the primary action button as they’re scanning. Their eyes will land right on it when they’re through, so they can click it right away.
Scanning the dialog box and taking action is fast and easy because the users eyes end on the primary action button.
Place the buttons in the corners, or keep them together?
Another question designers often wonder with dialog box buttons is whether they should place them in the corners or keep them together. When you place your primary and secondary actions in the corners of the dialog box, it maps to the left and right navigating directions really well. However, since ‘Ok’ and ‘Cancel’ buttons aren’t exactly pagination buttons, following the directional mapping rigorously isn’t necessary. In fact, sometimes, it can do more harm than good.
The large visual separation between the buttons makes comparing actions difficult and isolates one action from the other.
If the application is about to carry out a crucial action that the user cannot undo, it’s important that users can see the ‘Cancel’ button along with the ‘Ok’ button. In this case, the ‘Cancel’ button might function like a ‘Previous’ button, but it is more important than it because it acts as a safety button to prevent any changes. The danger of placing the ‘Cancel’ button in the far left corner is that it can cause users to overlook it due to the large visual separation between the two buttons. Putting the ‘Cancel’ button together with the ‘Ok’ button makes it easier for users to see both buttons. This allows users to efficiently compare the two actions in a single gaze to choose the best action to take.
Conclusion
Designers often use dialog boxes when there’s an important message users need to read, or an important action they need to take. The order you place your buttons can affect which action the user chooses. When you place your buttons in an order that is clear and efficient to users, you can prevent them from choosing the wrong action and making a serious mistake.
Button placement is important, but remember to also pay attention to the visual weight and labels you give your buttons. All of these design aspects come into play when users process dialog boxes. Now that you understand the reasons why ‘Ok’ buttons work best on the right, you’ll have something more to refer to when figuring out button placement than the flimsy platform consistency argument.
Vincent
May 26th, 2011
Although I agree, this is based on the assumption that the user reads from left to right.
I was wondering if the reverse applies to users who read from right to left — with ‘OK’ button aligned to the bottom left of a dialog box.
Pepper
May 26th, 2011
Yes, typically a right-to-left interface will have all the dialogs in a mirror image in which case “Ok” would be in the far left corner with “Cancel” just to the right of it.
Daan
Jul 6th, 2012
With the exception that someone reading from right to left may be used to reading from left to right when he / she uses the internet.
krembo99
Mar 23rd, 2014
You can not really read an RTL language from left to right , internet or not . No exception here ..
Azeroth
May 26th, 2011
Although your arguments make a lot of sense, please don’t go around now making Windows software with the wrong (for Windows) button order. It’s really really really annoying and people will click the wrong button all the time in your software.
Of course, you can use this button order for web applications and games with unique UI.
Paris
Jun 7th, 2011
I think the distance between each button is critical to afford the user room for miss-clicking.
Also, color could be added to imply the consequence of the action when possible.
Actual colors used would depend on the app’s color palette, but the somewhat universal options would be:
Red, Yellow, Green = Negative, Neutral, Positive
So the Cancel button would be negatively colored and the OK button positively colored.
Yollie
Feb 19th, 2012
Remember many people are color blind too.
asdf
Jun 22nd, 2013
So what?
Firstly: Many MANY many more people are not color blind.
Secondly: Colored buttons are not rendered unusable/unreadable to color blind people in any way.
Sergey
Sep 27th, 2013
Somewhere between 7-10% males and up to 1% females are color blind in various degrees. So I don’t think you can say that many MANY many more people are not color blind. 5% of users is a lot to start paying attention to.
Laird Nelson
May 26th, 2011
More important than any of this is that it should be “OK”, not “Ok”.
Senthil Kumar B
Jun 17th, 2012
@Nelcon – Well Notiiced
Aeomer
Feb 16th, 2014
No, it should be “Okay”
Also, would developers please *stop* putting both “Cancel” and “Apply” and rounding it off with an “OK”. Unless you will undo all the “Applied” settings the button should be “Close”. “Cancel” is ambiguous, confusing, and often straight up wrong.
So have “Close”, “Apply”, “Okay”.
“Apply” is disabled if no changes are made.
“Okay” is disabled if no changes are made.
“Close” is always enabled.
When a change is made, both “Apply” and “Okay” are enabled.
Clicking “Apply” applies the changes and keeps the dialog open.
Clicking “Okay” applies the changes and closes the dialog.
Clicking “Close” dismissing the dialog without applying the most recent changes.
Now, if you think “Close” is ambiguous in these cases because of a known edge case, the simple answer is to have “Cancel” until after the first time the “Apply” button is used in the current dialog instance (not across instances of the same dialog) and then changes to “Close” to show the currently applied changes will not be undone.
When did every developer on the planet forget these simple GUI rules we used since the 80s.
Aeomer
Feb 16th, 2014
Actually, I agree with a post further down. “Okay” should not be used in this case – use “Save” or “Commit” instead of “Okay” in a dialog that used “Apply”. Just replace “Okay” with “Save” in my rant.
Mark S
May 26th, 2011
In my opinion the reason windows buttons have cancel on the right, is that cancel is less detrimental to most processes than accepting the action.
A cancel can also be confirmed, without causing too much distress, confirming every positive action however would be a nightmare
Matt
May 27th, 2011
I Agree ..
Besides:
Offline you’d ask someone “Would you like this/that? – Yes or No”
Semantically, OK/Cancel is the same as Yes/No
In practise, this article is opting for asking people No / Yes?
I’m sticking with OK / Cancel for the reason above. For extra contrast, OK could be a button or a brighter colour, the Cancel could be a link or less bright ..
anthony
May 27th, 2011
How is the way you would ask someone a question offline relevant in this particular online context? And how do you equate a ‘Yes/No’ question typically seen on a paper form to a user interface dialog box that executes a process as one and the same?
This is the perfect example of not using reasoning, but mere assumption to make a design decision.
Harpreet Singh
Oct 3rd, 2011
OK as button and Cancel as link is more appealing as the user can easily guess/decide the primary action.
Mike McNally
May 27th, 2011
I agree – or, to put it another way, the presumption that the best thing for the design is to minimize the amount of time it takes for the user to scan to the button they want is not necessarily applicable to every situation. Anybody remember the way that the old WinZip shareware would scramble the buttons on the nag dialog when it started up? The point was to make the user think about it (and yes, it was annoying, but the designer knew that).
anthony
May 27th, 2011
If the ‘Cancel’ button is less detrimental to most processes shouldn’t it be on the left, where users can accidentally click it without causing damage? Wouldn’t placing the ‘Ok’ button on the left be more detrimental, since it’s closer to users and easier for users to accidentally click? It seems to me your reasoning is flawed.
Nathan Phillip Brink (binki)
Feb 1st, 2013
As a previous commenter said, switching around the well-defined order of OK/Cancel buttons is more likely to result in users miss-clicking than placing it “closer” to users. Many users do not even look at the buttons before clicking in the lower right-hand corner (or pressing ‘c’ or ALT-‘c’ or ESC) with the intention of cancelling the action.
In Windows, the button in the lower-right hand corner of a dialog box is always “No”, “Cancel”, or some other safe non-action.
Platform consistency matters. Platform inconsistency forces the user to take time to think, like for WinZIP’s “buy me!” popup mentioned above. Users will get frustrated with your product if you consider it special enough to defy the standard UI. If you’re writing in C# on Windows.Forms, _always_ use MessageBox and one of MessageBoxButtons. GTK+ has GtkMessageDialog and GtkButtonsType to help you. “Fixing” the order of the OK/Cancel buttons in a simple dialog box has to be done _in_ the platform itself.
Paul Bennett
May 26th, 2011
I think quite often you know you’re going to be pressing OK before you even get to the buttons – in that case placing the OK button on the left is actually more efficient because you don’t have to scan across both buttons before you click. The Cancel button can be completely ignored.
aJanuary
Jun 17th, 2012
Equally, consistently placing the OK button on the far right means you don’t have to scan across both buttons.
On most modern operating systems the default action (OK) is highlighted and where the eye will most immediately track to, regardless of location.
Vladimir
May 26th, 2011
Good points and hints.
I like my OK buttons on the right too
button action cancel dialog comment
for its contents. This is a safe-cache copy of the original web site.