Designers often question where to place their ‘Ok’ and ‘Cancel’ buttons on dialog boxes. The ‘Ok’ button is the primary action that completes the task.
The ‘Cancel’ button is the secondary action that takes users back to their original screen without completing the task. 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?
What if a certain design convention is harmful to users? Should designers blindly follow it for the sake of consistency? Should bad design practices 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. Understanding the reasons why you should design your user interface one way as opposed to another way is key.
Button Placement Matters
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 question which placement works best. You can solve this problem by analyzing how the design affects users.
Less visual fixations
It’s necessary to see if the common assumptions designers make are true. 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 are 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 the terminal 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 user’s eyes end on the primary action button.
Buttons in the Corners or Keep Them Together?
Another question designers often wonder is whether they should place the buttons 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 well. However, since ‘Ok’ and ‘Cancel’ buttons aren’t navigation buttons, following the directional mapping isn’t necessary. 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’s more important 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 and compare the two actions in a single gaze to choose the best one.
Conclusion
Designers often use dialog boxes when there’s an important message users need to read or 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 prevent them from choosing the wrong action and making a mistake.
Button placement is important, but remember to also pay attention to the visual weight and labels of your buttons. All these design aspects come into play when users scan dialog boxes. Now that you understand the why ‘Ok’ buttons work best on the right, you’ll have a better argument to reference than the platform consistency one.
Book
Affiliate
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.
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.
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.
You can not really read an RTL language from left to right , internet or not . No exception here ..
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.
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.
Remember many people are color blind too.
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.
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.
More important than any of this is that it should be “OK”, not “Ok”. 🙂
@Nelcon – Well Notiiced 🙂
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.
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.
Actually it is “O.K.” not “Okay”; it’s an abbreviation and ‘Okay’ is the pronunciation of that abbreviation — https://en.oxforddictionaries.com/explore/what-is-the-origin-of-the-word-ok /OCD
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
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 ..
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.
OK as button and Cancel as link is more appealing as the user can easily guess/decide the primary action.
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).
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.
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.
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.
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.
Good points and hints.
I like my OK buttons on the right too 🙂
What I want to know is whether you should hang the toilet paper so the free sheet is on the front or on the back.
What do you do? Please leave a comment below.
front
agreed
I used to think that there were two types of people in the world: (A) Those who always have the TP coming out over the top of the roll; and (B) Those who don’t care and get it right about half the time.
Then, I met a third type of person: One who had a mischievous, young cat, and who made it a point to always have the TP hanging off the back of the roll so that the cat couldn’t easily unspool it all onto the floor.
I think what would be more helpful is if the ‘secondary action’ were more visually different from the ‘primary action’ on various platforms. Windows dialog boxes should style the appearance of the “Cancel” button differently than the “OK” button. Interesting that MS (for example) hasn’t taken their UI design efforts to that level of detail.
Alex, they do, and have for some time (Windows 95?, maybe even the 3.x series)
Example:
http://www.java2s.com/Code/PythonImages/OKcanceldialogbox.PNG
Note that the OK button has a thick outline, whereas the cancel button does not.
Two more examples using different styles, another subtle one:
http://www.indigorose.com/webhelp/suf9/Users_Guide/Users_Guide_files/chap_4_dialog_message_okcancel.png
And a not-so-subtle one:
http://2000thingswpf.files.wordpress.com/2011/06/001-okcancel.png?w=314&h=236
In order for a dialog button (in any dialog) to be styled that way, all the developer has to do is make that button the ‘default button’ that gets ‘pressed’ if the user were to hit the enter key (without a keyboard input element having focus).
Omg, seriously? The fat border and blue color only indicate the current tab position. And if you press the tab key, the border/blue color would mve to the next item. Your point is totally useless.
No is not, the point is totally valid because if you move the tab position to the next index the Ok button will still display with emphasis.
But what I really get from this article is “I love Mac UI, I dont like Windows UI”, no one here has the fault of Mac trying to be different, I preffer the Ok button on the left side, and the close button on the far top right side, even if mac users dont like, it feels easier than mac approach, I always get the “when you get used to mac you’ll see” but I’m far from getting used to it, in fact take a look: facebook, google and even in this link http://support.apple.com/kb/HT6312?viewlocale=en_US apple has the Yes/No options for the “Was this helpful?” question and not the No/Yes as the writer says is better for users, It just feels wrong if you find “Was this helpful? [No] [Yes]” rather than “Was this helpful? [Yes] [No]”.
I would argue that the majority of computer users have OK (left) and Cancel (right) placement in their long term memory. Switching the button labels makes them inconsistent with the user’s expectation, perhaps making the decision time longer. Unless the dialog box is presenting a system-critical message, I don’t see a need to have OK on the right.
Mental models are important. A developer in my company put the OK on the right before I read this, and it just bothered me. It’s like putting the “Home” link on a website navbar on the right. Although it might be more efficient (look through links and then go home) it just feels…wrong.
From a web accessibility point of view I advice to put the default button first in the markup code. Of course, the visual positioning can be different from the underlying structure.
In my opinion are “ok” and “cancel” the very poor labels? Please use actual actions that are relevant to the dialog? e.g use Keep/Discard, Cancel/Quit, Cancel/Empty Trash, or Cancel/Join,
I agree! Then they don’t even need to read the statement at all!
Exactly what I have thought and practiced. If it’s possible in any scenario, please use actual actions on the buttons rather than OK/Cancel combo, the user will have hard time knowing what they will be doing with the OK/Cancel without reading the instruction carefully.
And when using actual actions in button, I find it the best to put them in the middle of the dialog.
I completely agree.
Examples:
– “Save”, “Discard”, “Close without saving”.
– “Shut down”, “Cancel”
– “Delete permanently”, “Cancel”
(or of course, the same buttons but in the reverse order).
You surely meant “Discard/Keep, Quit/Cancel, Empty Trash/Cancel, or Join/Cancel”!
These are interesting points – particularly the ‘eye flow’ and aligning the buttons with the left/right action flow of going back or submitting/confirming a choice.
Another Confirm/Cancel paradigm I’ve been noticing a lot on the web is making “Cancel” a text hyperlink as opposed to a button. This way, you’re getting the user to focus on the button with Cancel being the secondary and less probable action. In this case, I mostly see Submit/OK to the left of the cancel hyperlink, but I suppose there’s no law that says you couldn’t put the button to the right of the text link.
This use of hyperlinks on websites for Cancel buttons may just be to avoid form submission in the first place. Implementing Cancel as a button (without the help of JavaScript) requires detecting which button was pressed in server-side code and, often, a redirect to a different page. A hyperlink just puts the user directly at the destination page, preventing the browser from submitting the form in the first place or needing to follow a redirect. Thus, a hyperlink may be desirable and used (for technical reasons or laziness) even when the interface would look much more natural with a button.
Placement of OK, CANCEL buttons – There have been a long-standing discusses about the placement of these buttons.
It principally comes down to two contrary viewpoints.
One viewpoint is …, that the OK button have to be placed to the left of the CANCEL button. The reason for this first opinion is because we read from left to right, top to bottom, buttons should be placed left to right in order of importance, importance being how likely a button will be used.
The second viewpoint says that because we read from left to right and from the top to bottom – in most parts of the world. The left side is typically implicit as being BACK and the right side is implicit as being FORWARD. When we look at our browsers it´s almost the same – the BACK is on the left and FORWARD buttons on the right have arrows – pointing left and right in that order. The function Cancel is a back action and OK is a FORWARD action, the OK button should be to the right of the CANCEL button.
I concur with the second viewpoint, as it is more consistent. I strongly believe that CANCEL always goes on the left, and OK always goes on the right.
( – On rare occasions I reverse this “common” practice – when I will avoid interruptions or abort by the user – )
Two hints regarding this button placement:
http://www.useit.com/alertbox/ok-cancel.html
http://measuringux.com/SubmitCancel/index.htm
Two hints regarding form design in general:
http://www.lukew.com/resources/articles/UI12_LukeW_WebForms.pdf
http://ux4dotcom.blogspot.com/2009/06/form-of-forms-we-need-them-but-also.html
I disagree, the Cancel should be most right, and the reason I give is consistency but not operating system consistency.
Don’t underestimate the importance of the cancel button – It’s the most trusted button on a computer. The user trusts that hitting cancel will bring them back to the previous state with no changes (and side note: we should never break that trust)
Moving the Cancel to the most right means it moves – position is different for Cancel, OK and Cancel No Yes (Or whatever way you have it) as you said position is important and moving the button around implies it is different – and we lose the end users trust.
Having it the most right means it never moves – No matter what buttons you have up there, if there’s a cancel it’s in a consistent position, and that stability gives end users trust.
Say what?
I’m guessing he meant to say “Moving the Cancel to the most left means it moves”.
I just had an argument with a coworker about this very subject as the way I have implemented our buttons is in the ‘natural’ order (i.e. OK = forward = on the right, Cancel = ‘backward’ = on the left), with a possible third option between the two, although usually if there’s more than 1 choice I use radiobuttons instead.
However, his argument was that it should be consistent for a user to always know they can cancel what they were doing (be it a benign operation or something that could lose them hours of work (though those operations set an undo point, so not quite that bad)), by simply clicking the bottom-right corner button.
( I should note, at this point, that we’re not targeting RTL or even i18n, for that matter. )
In the way I’ve got things set up right now, this means that the cancel button ‘moves’. I.e. (imagine the following being right-aligned)
[ cancel ] [ no ] [ yes ]
[ cancel ] [ OK ]
So they would have to click the left-most button, and have to ‘scan’ to find that button first.
My counter-argument is that the same applies if the user wants to take positive action – having to ‘scan’ for the yes/OK button, and that the natural order makes more sense.
Ultimately, though, while going with the platform convention is ‘probably’ the best way to deal with things, users aren’t completely thick. Yes there will be some miss-clicks, but you’ll get miss-clicks no matter what you do with the buttons. However, users adapt. Users quickly learn the button conventions of a particular program. So the only truly important thing is that, within your application(s), you stay consistent. I.e. don’t put Cancel on the left in one dialog, and then on the right in another.
( And always set a default button if it’s okay to do so. If an action is particularly destructive, don’t set a default button. Don’t make ‘Cancel’ the default ‘enter’ button, that’s what the Escape key is for. )
“stay consistent within your program”
The discussion ends here. 🙂
I cannot recall seeing an “Cancel No Yes” dialog box. I have seen many dialog boxes with Back/Next, though. Next is always on the right, and Back is always on the left. If you put Cancel on the right, then you’ve created inconsistency between “wizards” and “all other dialog boxes”: to continue, click on the right, except when you click on the left.
Boy is this true.. I have, on several occasions, clicked “Cancel” without even reading the buttons or thinking about it when, in fact, the cancel button as actually the “Accept” button but “Cancel” was on the right for some reason..
The only thing I may not agree on is the large visual separation. In a dialog box as small as the one in your images, I think that space is generally negligible and may actually make it easier since most users won’t even look on both sides, but rather, quickly look in the direction which they expect the desired action to exist.. In the case of “Accept” or “Ok” that should be to the right..
Overall though you are spot on.. Thanks a lot for sharing..
It would aid the credibility of your argument if you were able not to display a foreigner’s kind of dyslexia and realized that the buttons you are talking about are OK and not Ok buttons.
Can you not see the difference, even in this comment?
interesting… I like the OK button on the right, too.
certainly the last example is very effective. Both should be separate buttons in the corner
Always i do first OK and on right another. By reading direction. It is natural for us I think.
What about colors? A red cancel and green OK button?
So small thing and so much it can do. Very interesting article, nice examples. Wonderful work!
Nice post! An interesting approach is to head the user’s action through colors also. Red and green causes a distinct reaction, plus the right position of buttons we can have the perfect UI.
Can’t say I totally agree. Every now and then I happen across a site that does this, and after 10+ years of always seeing Yes/No or OK/Cancel, I have accidentally hit cancel 1/2 of the times it has been done as Cancel/OK.
Don’t get me wrong, I am not saying everyone is like me, but after so long of this being done one way, switching it up for “usability” seems to be defeating that purpose, as some people will inevitably try to do what they are used to doing with these boxes, and end up making the wrong choice.
Another thought, if you expect “OK” to be the default response, why not put it first? It seems “Cancel” is only needed in the event that someone is unhappy with the situation, so they would continue further only if there is a reason to.
Finding the OK works well if that is your intention, and if people are constantly getting dialogs that they want to cancel, you might have a much larger usability issue.
One further point is that on mobile’s, most people use their right thumb as the main tool for navigating, so the right hand side is less of a strain.
I’m impressed – I found this to be an exceptionally well-reasoned and well-written article. The reasoning rings true with my overall life philosophy… Doing anything solely because “that’s how it’s always been done” is a surefire way to guarantee stagnation and the halting of progress/advancement/improvement.
@Chris McGrath: What you’re talking about is pandering to the stupidity of the masses. You gain a user’s trust first and foremost by developing a useful and stable product. If well-reasoned differences in UI design could cause so epic a who-moved-my-cheese devastation in users, then said users wouldn’t last long on this ever-evolving and adapting planet in the first place and would most likely be up for a Darwin Award in the very imminent future.
Buttons, you definitely need them. Love the last bit about the separate buttons. I prefer ok to the left and cancel to the right. We have been working with such dialogue boxes all our lives, so the hand automatically goes to click the first button for a positive response. So automatically I tend to click on the first box.
Again: The word is OK or okay (rarely seen in computer UI), but only to a foreigner or an illiterate is it Ok.
The English language does evolve. I’ve seen Ok around quite a bit.
I think this is what’s happening..
oll korrect (from illiterate people miss spelling “all correct” in Boston)-> O.K. -> OK -> okay -> ok
The capitalized version of the last one is Ok.
In a decade it will just be “k” or “K” XD.
The comments seem to demonstrate that users will have widely varying perspectives. Accessibility and context were two particularly objective examples given above, but even the variation in subjective preferences expressed by commenters suggests the potential problem of relying on opinion.
That said of course guidelines are necessary. Just not sure you’ve hit on one here. The accessibility of putting the default first is a decent argument, for one.
Thanks for this food for thought! There are so many factors that come into play, a lot of the time you have to go with what you feel works best for usability. I personally prefer a small hyperlink for cancel and a button for the desired action, preferably in an appropriate colour. I don’t really like relying on placement alone when other factors like size, colour and whether you use a hyperlink or button can make a huge difference.
I always struggle using Halifax online banking because all their call-to-actions look the same. They force the user to read them and yes, i’ve often clicked the wrong one because of this! :p
I’ve never been fond of the ‘use a link’ method – at least certainly not in a desktop or mobile application.
A link usually indicates that the user will be navigated to a different location. Be that part of a page or site (typical web navigation) or a different window related to the action at hand (i.e. Windows help file links opening a particular control panel applet).
So when presented with a dialog:
“This will cause the destruction of planet Earth.”, where there is only an OK button and some link which at first glance I would only expect to take me ‘somewhere else’, there’s a moment of “wait, no, I don’t want to destroy Earth! Where’s my cancel button?? I don’t see a cancel button! ARGH!”.
It’s only after I’d read the full text used for the link, e.g. “No, let’s not destroy Earth today”, that I’d know that the link is actually part of the decision tree.
While that does force some actual reading of the options – which is a good thing for user-awareness – the presentation and conventional association with these forms is likely to cause initial confusion.
Pingback: Design Basics: Flow Is Why The "OK" Is Always On The Right | t3knoDorKs
Some good comments above but think from a useability point of view, if your UI has similar buttons and look to a main-stream website, then it makes sense to copy what they are doing unless you can afford a decent amount of user testing.
However, if you have an original looking website design, then I think the colour, shape and size argument kicks in and if clients aren’t subconsciously looking for similarities in sites they already use, then you can probably use a new approach to your advantage and not suffer from a more innovative approach.
Disagree.
I’ve been an user on both sides of this.
OK-Cancel: Windows, Android
Cancel-OK: Mac OS
I was an avid Windows guy.
I switched to the Mac three years ago.
I have an Android phone.
There are a few considerations that go into such a problem:
consistency
speed
first-timers vs power users
I’m in favor of OK-Cancel for efficiency purposes. I find the Windows way the most efficient. One word question in the title of the dialog, main action as the left-most button. Delete? OK! 99.9% of the time I meant to do that. Make it efficient for crying out loud. If I’m confused, I’ll read the dialog text as well as the button labels.
As a long time Windows user, I loved how mindless was the process of using dialog boxes. If a dialog box popped up and it got there because of some action I understood (such as right click > delete on a file) I wouldn’t read anything. I just clicked the left-most button. No, there were no accidents. It just worked.
After three years of using Mac OS across home and work, I still have to read the darn button labels!
Yes, let me also respectfully disagree with the conclusion here.
I think the key part there is the question part. Before OK and cancel there is a question. “Would you like to do something?” There the ultimate consistency issue is consistency with the real world. What do people do and think in the real world? I would find it safe to argue that people think Yes/No, not No/Yes.
The fact that then Windows with its OK/Cancel is the most popular pattern that users know from computer systems of course also helps, but I would argue that they’ve modelled this way based on what makes most sense in real life.
For example for a query dialog, replacing “OK” and “Cancel” with the words “yes” and “no”, you wouldn’t want to say “Do you want to connect to this wireless hotspot?” with No being the first option, then yes.
Considering visual fixations, I think you’re also a bit analyzing this like how a robot would see the situation. The robot would read all the labels all the time, one by one. But once again here consistency IS the key: Humans learn the shape and size and overall pattern of OK/Cancel after seeing it for the nth time. They do not have to read both the labels, they recognize the overall OK/Cancel as one element and can react instantly to it.
And yes, people in western cultures start reading from left to right. Spotting OK is faster when it is the first action.
(That is why I think OK/Cancel actually works really well. I’ve heard good arguments why the command buttons should be replaced by the actual commands, like Send/Discard, but in this case the users do have to read them every time and then then think about the commands.)
People read the query and think about it, and they come to a positive or negative conclusion. There are exception cases where OK and Cancel are then a bit ambigious, and exceptions are always sometimes needed, but then you could argue that the original query is poorly writtern.
Ultimately I find this article a bit worrying when arguing that “consistency is not enough without understanding the problem in a deeper level” – which is fine as a statement by itself – but then at least the deeper level analysis here to be a rather superficial visual analysis, not a really mental and cognitive analysis of what people think and how they react and what they have learned when seeing OK and Cancel over and over and over again, vs. what happens when occasionally the expectation of these people is reversed.
It is not worth the tradeoff.
Confusion is worse than the gain of flow.
It causes the user to pause on the difference. Negating the gain.
If the user is highly conditioned to traditional placement, this is an added frustration.
Good points on UX, but in this case it is, unfortunately, not worth the tradeoff.
Oh man. This is like saying blue is the best color.
Instead of writing false facts about form design, I’d strongly suggest dig deeper. Reading Caroline Jarrett and Luke Wroblewski’s books about form design will get you started. You’ll see things are not so black-n-white.
“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.”
It’s the opposite. Inexperienced designers only use their judgement. It is when you do user testing that you really start to understand – things are not so simple and just trying to think from users’ perspective hardly does the trick.
This. I really think they’re over analyzing things in this article.
So benefit from this article is only that I know how this things works,
but in real prototyping anyway I will use OK button from a left side, due to platform consistency (if I am at desktop PC/ Web / Android mobile).
Thats of course good to know question deeply. But more useful to use that conclusion in practice. And for now – platform consistency is more important, even if there is worse UI within platform.
Interesting topic! I think the same principles hold up for the physical environment as in, for instance, elevator panels.
This is one of the most maddening things about Linux. Applications written using different toolkits (Qt, KDE, etc), all have completely different philosophies and reasons for which way they put their buttons.
At the end of the day, I really don’t care what an expert thinks the best arrangement of ok/cancel is on dialog boxes. I want a system wide setting that overrides all those so on my system I will always find ok and cancel in the same arrangement. Meaning, individual designers should give up some control and provide a hook so that their arrangement can be overridden into something more consistent system-wide.
Interesting point you make, but I think there are larger issues to dialogue boxes than just button placement. First of all, the buttons are only part of the solution. The meat of the matter in a dialogue box is the context in which it is brought up, followed by the supportive content that clarifies its purpose. It’s not so much the placement of the buttons, but the labeling of them, which many commenters have posted. There’s also some work done by Luke Wroblewski, the form guy, who’s found that by placing the primary action button (OK in your case) on the left, resulted in fewer fixations, because it followed the users scan line, from top to bottom. I’d argue that its more than just the placement. There’s an ecosystem of content, visual distinction and placement based on how you want to guide the user to making a decision. Just my thoughts 🙂
Here’s my 2 cents:
http://i.imgur.com/mwXph.png
1. ‘OK’ should *never* be used. The primary button should dictate an ACTION – ‘save’, ‘add’, ‘confirm edit’, whatever. The only time OK should be used is if it’s on its own in a confirmation dialog… and even then, I’d suggest being more descriptive/engaging with your labels.
2. Keep with the flow; the primary action button should start as if you’re reading another line, as a continuation of the dialogue… in this case, left to right. (Though in other countries this may be reversed)
3. Visual priority is very important, more important than you make out in this article. If a user’s performed an action, we have to assume they want to perform that action. Cancelling is secondary, and it should LOOK secondary.
4. Following from the previous point, if all choices are equal, they should look equal.
Totally agree with Aiden, The Action Button text should use verb that reconfirms the action the user is about to take. “Apply”, “Create”, “Save” etc.
Boy is this true.. I have, on several occasions, clicked “Cancel” without even reading the buttons or thinking about it when, in fact, the cancel button as actually the “Accept” button but “Cancel” was on the right for some reason..
The only thing I may not agree on is the large visual separation. In a dialog box as small as the one in your images, I think that space is generally negligible and may actually make it easier since most users won’t even look on both sides, but rather, quickly look in the direction which they expect the desired action to exist.. In the case of “Accept” or “Ok” that should be to the right..
Overall though you are spot on.. Thanks a lot for sharing..
Why even have both buttons next to each other?.. yes, I read the part about users seeing both actions, and clearly knowing their actions, but c’mon, for the most part we and our users want to continue and I have found it more harmful than helpful to have them both side-by-side. These days everyone is accustom to clicking the “x” close button on a windows title bar to close/exit/cancel. To me the optimal choice is having the positive call to action button on the lower right, and the “x” close window on the right side of the title bar.
You make the assumption that people read the buttons individually. Especially with OK and Cancel buttons, they are easily recognized with a singular glance, not a true swipe of the eyes.
Like an above commenter posted, it’s a Yes/No response, not No/Yes.
I’ll tell you what takes people off task, is breaking a mold that is universally established.
Changing the button position does not make people ask:
“What choice should I make?”
instead they ask:
“Why would they change the button position?”
Which in turn causes them to waste more time posting drivel in articles like this one.
Your button ploy worked on me I paid attention then posted a comment…That is the real reason you created this article is to pad your email list…It worked on me.
The amount of your supposed “time saving” is a concern if you are navigating through an asteroid field or calculating a hyper jump to planet Uzeliss, otherwise really you are making a problem where none exists.
Typical of a Designer and not a UI / UX professional.
The only intuitive interface is the nipple. After that it’s all learning and conditioning.
Professionals rarely make mistakes, therefore the most efficient pattern is a verb in the title bar of the dialog box such as “Delete?” and a “Yes” button as the leftmost button, so it’s the first encountered button.
Good post.
It depends on the application to application and the end users . Keep up the consitency whichever is used keeping the end users in mind …
In every picture of your dialog box you have a perfectly servicable close widget in the title bar, obviating the need for a separate “Cancel” button.
“OK” should appear bottom right for English, Farsi, Hebrew and Chinese localisations. If needed an “Information” button can appear bottom left. The Microsoft Windows order “OK”, “Cancel” throws off habituated clicks to the location of “OK” when “More Info…” buttons are appended beyond “Cancel”, forcing “OK” further left.
I just generally scanned over this post and briefly over comments made by other people. I get the jist; I understand the complete issue at hand, but I had this idea. This is was the first thing that came to my mind as I read over the post “Change the word ‘OK’ to ‘Confirm'”. This idea may, at first sound ignorant to solving the issue at hand, but I believe this word would work better with human psyche. Further, I would like to add that the order should be ‘Confirm’ then ‘Cancel’ because subconsciously we see, understand and are more familiar with a positive action before the other. Think of the ying-yang symbol, white is on the left black is to the right. White is seen as a positive and black as negative, both in equal and balanced portions. Pick up a double A or triple A battery and hold it so you can read the information along the body. With the battery I just did this with the positive end is on the left and negative to the right. I can’t say this is true for all batteries, but it just seems right for it to be that way. I’m just hypothesizing, but i would say that this would prove to work better. I seen a bunch of great comments here and love to see feedback. Thanks
I agree with this article’s reasoning. As trivial as this sounds, I’ve encountered complaints of data loss when after entering extensive information, only to lose it when “cancel” is inadvertently clicked instead of “save”! Convention matters, as evidenced by Mike McNally’s WinZip observation. I wonder if the confusion stems from differences between Windows and Mac operating systems. Mac OS X at least in my brief experience from Tiger to Mountain Lion seems to have all the confirmatory buttons on the right, cancel buttons on the left, whereas with Windows systems, it’s just the opposite.
I’m surprised there’s been no mention of button size. If the “OK” button is significantly wider than the “Cancel” button, it would hold prominence no matter in which order they appear.
I appreciate the effort put into this article, but I truly hope nobody follows this advice.
I agree with the comment above by Roope Rainisto (Aug 6th, 2011) and I’d like to expand upon it.
The first rule of UI design is “Manage user expectations.”
“Blind” UI tests indicate that users expect the first button to be the positive action. The test has the label “Do you you want to save?” and the buttons are both labelled “button”. Try this test with your users and you’ll see that the expectation is that the first button be the positive action.
Best practices:
1. Positive action, negative action.
2. Use descriptive labels.
3. Use buttons.
4. The positive action button(s) should be as big or bigger than the negative action button.
5. The buttons should be placed in the bottom right corner.
6. Minimize the plain text.
There are compelling arguments on both sides. Users will make mistakes no matter the button order, and not just because of the button order. Does being a square peg in a world of round pegs make you “right”? Adapt – conform to the platform. The user is right and for the vast majority this means that they learn from the platform what to expect as being right.
I am no designer but as a user I have a different arguement. My eyes automatically go to the left side and if I agree I click on it. Yes or agree had been on the left for a long time but sometimes cause I wouldnt read the left side I would click yes when I wanted to click no. For example I accidentally pressed delete and then the box said are you sure you want to delete this, yes or no and id click on yes absentmindedly. So by reversing the position of the buttons that stops me from making a mistake. No harm done if I click on no, I can always perform the task again and click next. The reversal allows us to this read both the options and then decide
Actually, it really doesn’t matter. There are many arguments for the opposite layout too.
But I think that it really doesn’t matter. The only thing that’s important here is consistency. Every dialog of all software on EVERY PLATFORM should be the same.
I think the biggest problems here are Microsoft and Apple who have conflicting design guidelines. If these two agreed on it, I’m sure all other platforms would follow suit. But they don’t care about cross-platform developers who have more work because of them, nor the they care about the users.
As a user I often use different platforms (at home, at school…) and every time there’s a change in the placement of buttons like OK and Cancel, I click the wrong one at least once. And it’s even worse on Linux, because KDE and GNOME have conflicting design guidelines and if you use software from both, you’re bound to err.
great points. One should definitely be mindful of falling into the habit of making design decisions based on ‘consistency’
My mind has recently told me that the “standard practice” has changed on Windows and/or the web.
My mind says ” it used to be OK on the right”, and I’m wondering “when did it change?”.
Or am I getting confused by “OK on the right” in Anrdoid?
I’ve used Windows since Windows / 386 and the Internet since 1995.
Can anybody offer any documentary evidence of a CHANGE (new item or similar) or of a former “OK on the right” style preference (ancient style guide or what not) ???
Me, I prefer OK on the right.
In any OS specific applications, desktop, mobile, tablet etc. follow the standards! they are provided in the UX design guideline from Apple and similar documentation from Windows and Android.
On the web: much more difficult. Also because we are starting to build web apps that should in theory behave like desktop programs but just work in the cloud.
1) make it OS dependent. That’s consistent, unless your users have a macbook for some tasks and an android tablet for other tasks or use situations – then OK and cancel would keep shifting…
2) Make a firm stand and be consistent within your own application. Then best to respect Windows standard most, since probably most of your use-base are Windows users anyway. Put cancel at the end/right. But follow also Luke W.’s recommendations of visual distinguishing actions. Keep Cancel to right as a grey button or link. Have the primary action (often OK) as the second from right and in color. Distinguish the rest of the buttons by color and also create groups or distance between primary and secondary buttons (like prev/next and OK/cancel)
If i was making an OK+ Cancel form without any bias i would make it
Cancel – OK
i guess this is because i see OK as a ‘Next’ and cancel as a back button
If i add colour, with red for cancel and green for ok i further feel green-OK should be right
windows Apply button is on the right with OK on the left
I appreciate (but do not like) the consistency argument. As a previous poster states its a slippery to stagnation
the number pad on a keyboard vs number pad on a phone annoyance of mine but it never causes issues
I agree with Aiden.
I always put the “OK” button to the left. Think when a form is used. When you use the TAB, for exampl: You click “tab-Tab-Tab” and then “OK or Accept”.
I find this rhetoric for putting OK on the right reasonable in discussion behind closed doors in a theoretical environment. But we are talking about something SO MINUSCULE. Seriously, we’re talking about the placement of two buttons on a form where 95% of people expect OK to be on the left.
We’re not engineering the back end, we’re not building a bridge. Consistency (what users expect) is 100% a valid argument.
No software designer here … just a CAD/Data input (GIS) user whose measured mouse-click count per day exceeds 6500 … that’s a LOT frk’n of clicking.
If there were a way that a user could CUSTOMIZE THE LOCATION OF THE “OK” BUTTON to always be where s/he wanted (and expected) it to be it would save HUGE amounts of ergo-nightmares.
I use seven different programs and am constantly moving my arm/wrist all over the desk looking for where a software designer has “hidden” the OK button. I’m right-handed – I would locate “my” OK button at the lower right corner, just above the toolbar.
Just Want to add one point. Do you think that it depends upon context of using application and Primary Action? Like if a using the same application on daily basis, and it has the same Modal Dialogue so in this situation placing primary action on the extreme left makes sense. Because it might save users extra eye movement till the end.
Need your thoughts! 🙂
Just one small problem: Cancel is the primary (non-destructive) option.
This thread shows how different opinions can be on such a small thing and how important the subject is due to the fact that these buttons are used frequently every day.
It would certainly be of advantage if a standard would be used everywhere, however different personal preferences make it difficult to achieve.
I once got the chance to read parts of the Apple GUI style guide. It was impressively logical and consistent – and far from being useful.
The detail of the analysis of mouse movements, eye movements, clicks etc. was extraordinary. However in practice the results weren’t good enough, in my opinion, because, I believe, the criteria analysed weren’t chosen well.
E.g. if there were two fields next to each other, like attribute name and attribute value, the first would be aligned to the right while the second would be left aligned. The reason given for this was that the eyes would have to move less between name and value. However reading only the names in order to find a particular one would be very hard with such a concept.
The order of the buttons and most of UI should be left alone much like the QWERTY keyboard.
The reading/scanning direction argument has limited merit: experienced users do not necessarily read the text that is written on the buttons. The standard buttons are occasionally labelled differently, possibly under a misguided user experience rule: OK/Cancel, Accept/Deny, Yes/No, or have icons indicating the action (checkmark, cross, crossed circle), and these differences can be easily ignored when switching between applications from different vendors or released at different times. The first button performs the action, the other button does not. The text in the message, which the buttons are a response to, doesn’t neccessarily have to be long enough to fill the entire window up to the right-most button.
I seem to recall that in some DOS/Windows applications the dialog layout was sometimes broken as a rare exception, if the action had grave consequences, such as if the partition table gets erased or something. Then “automatically” pressing Enter performs the No choice, which is fine if the dialog is called up rarely and all the user’s full attention is required.
Old post, I realize that.
I disagree, CONSISTENCY is really important to me. I CANNOT STAND how some people have it OK CANCEL others have it CANCEL OK. Be consistent. If I had my druthers, there would be a law MANDATING it–yes, you would be FORCED and ORDERED to do it the same, EVERY SINGLE PROGRAM everywhere would be MADE to do it all the same. I’m getting tired of pressing the wrong one by accident on account of being used to one way and then someone has to get cute and change everything. LEAVE IT ALONE!!!!
Interesting arguments, i’ve never thought of those. But so are comments as well. What i really would like to do is to have some switch in Windows to change places for Ok/Cancel and try it for few days.
I would argue that the majority of computer users have OK (left) and Cancel (right) placement in their long term memory. Switching the button labels makes them inconsistent with the user’s expectation, perhaps making the decision time longer. Unless the dialog box is presenting a system-critical message, I don’t see a need to have OK on the right.
Complete non-sense. It depends on your clicking routine. We’re just used to click them on the left side rather than the right. What if it WAS designed the other way around? I bet you’d write an article about “Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Left”.