Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right

by 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.

Why Ok Buttons in Dialog Boxes Work Best on the RightWith the ‘Ok’ button on the left, the visual fixations are more and flow in multiple directions.

Why Ok Buttons in Dialog Boxes Work Best on the RightWith 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.

Why Ok Buttons in Dialog Boxes Work Best on the Right‘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.

Why Ok Buttons in Dialog Boxes Work Best on the RightScanning 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.

Why Ok Buttons in Dialog Boxes Work Best on the RightThe 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.


Why Ok Buttons in Dialog Boxes Work Best on the Right Why Ok Buttons in Dialog Boxes Work Best on the Right

Author and editor-in-chief of UX Movement. Loves great web experiences and fights for the user.

98 Responses to “Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right”

  1. 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 ..

  2. 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.

  3. 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.

  4. 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.

      • 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.

  5. 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.

  6. Vladimir

    May 26th, 2011

    Good points and hints.
    I like my OK buttons on the right too :)

  7. Adrian Short

    May 26th, 2011

    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.

    • Alex

      May 27th, 2011

      front

    • Will

      May 21st, 2014

      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.

  8. Alex Burr

    May 26th, 2011

    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.

    • Steven

      Jun 15th, 2011

      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).

      • fuzzed

        Aug 7th, 2013

        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.

        • George

          Oct 8th, 2014

          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]“.

  9. e1m1

    May 26th, 2011

    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.

    • Robin

      Oct 21st, 2011

      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.

  10. Gino Lardon

    May 26th, 2011

    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.

  11. Gideon

    May 26th, 2011

    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,

    • Robin

      Oct 21st, 2011

      I agree! Then they don’t even need to read the statement at all!

    • Taylor

      Jan 3rd, 2012

      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.

    • Flimm

      Jun 17th, 2012

      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”!

  12. Alex

    May 27th, 2011

    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.

  13. Holger

    May 27th, 2011

    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

  14. Chris McGrath

    May 29th, 2011

    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.

    • anthony

      Jun 2nd, 2011

      Say what?

      • Steven

        Jun 15th, 2011

        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. )

        • Robin

          Oct 21st, 2011

          “stay consistent within your program”

          The discussion ends here. :)

    • Alex

      Jun 17th, 2012

      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.

  15. Eric Bieller

    May 29th, 2011

    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..

  16. Joe Clark

    May 30th, 2011

    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?

  17. Tyler

    Jun 3rd, 2011

    interesting… I like the OK button on the right, too.

  18. iddaa tahminleri

    Jun 6th, 2011

    certainly the last example is very effective. Both should be separate buttons in the corner

  19. Jan Bures

    Jun 7th, 2011

    Always i do first OK and on right another. By reading direction. It is natural for us I think.

  20. Adam

    Jun 7th, 2011

    What about colors? A red cancel and green OK button?

  21. Stanisław Chmiela

    Jun 7th, 2011

    So small thing and so much it can do. Very interesting article, nice examples. Wonderful work!

  22. Edson

    Jun 7th, 2011

    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.

  23. Joe Cochran

    Jun 7th, 2011

    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.

  24. Jn

    Jun 7th, 2011

    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.

  25. Penny

    Jun 8th, 2011

    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.

  26. Progeria

    Jun 8th, 2011

    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.

  27. Joe Clark

    Jun 8th, 2011

    Again: The word is OK or okay (rarely seen in computer UI), but only to a foreigner or an illiterate is it Ok.

    • Robin

      Oct 21st, 2011

      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.

  28. Kristi

    Jun 9th, 2011

    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.

  29. Lisa

    Jun 13th, 2011

    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

    • Steven

      Jun 15th, 2011

      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.

  30. [...] design-literate: wondering since certain things are a approach they are in a products we use. I only review a good (but technical) article that explained since “OK” is roughly always on a right in discourse boxes on computers. [...]

  31. Paul

    Jun 15th, 2011

    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.

  32. Heliodor

    Jun 19th, 2011

    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!

  33. Roope Rainisto

    Aug 6th, 2011

    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.

  34. Joe

    Aug 8th, 2011

    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.

  35. Jarmo Valmari

    Aug 23rd, 2011

    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.

    • Robin

      Oct 21st, 2011

      This. I really think they’re over analyzing things in this article.

  36. Viacheslav

    Sep 2nd, 2011

    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.

  37. Joren van Dijk

    Sep 12th, 2011

    Interesting topic! I think the same principles hold up for the physical environment as in, for instance, elevator panels.

  38. Kerry

    Dec 20th, 2011

    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.

  39. Parth

    Jan 4th, 2012

    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 :)

  40. Aidan

    Jan 11th, 2012

    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.

    • Sumi

      Jan 10th, 2014

      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.

  41. bouton OK

    Jan 18th, 2012

    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..

  42. Manny

    Mar 23rd, 2012

    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.

  43. Mark

    May 3rd, 2012

    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.

  44. Roxy

    May 6th, 2012

    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.

  45. Ben

    Jun 16th, 2012

    The only intuitive interface is the nipple. After that it’s all learning and conditioning.

  46. Heliodor Jalba

    Jun 17th, 2012

    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.

  47. Senthil Kumar B

    Jun 17th, 2012

    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 …

  48. Uncompetative

    Jun 17th, 2012

    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.

  49. Zach

    Sep 19th, 2012

    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

  50. Stephen

    Nov 1st, 2012

    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.

  51. Russ

    Dec 18th, 2012

    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.

  52. Michael Hutchison

    Apr 17th, 2013

    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.

  53. Art Sprague

    May 15th, 2013

    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.

  54. Tanya Singh

    May 28th, 2013

    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

  55. asdf

    Jun 22nd, 2013

    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.

  56. nelson

    Jun 30th, 2013

    great points. One should definitely be mindful of falling into the habit of making design decisions based on ‘consistency’

  57. Wayne Erfling

    Nov 25th, 2013

    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.

  58. Martin

    Apr 7th, 2014

    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)

  59. Alex Samuel

    Apr 16th, 2014

    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

  60. Anibal Blasutti

    Jul 16th, 2014

    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”.

  61. Josh

    Nov 7th, 2014

    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.

Leave a Comment