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

by anthony on 05/25/11 at 11:30 pm

A question designers often wonder when designing dialog boxes is where to place their ‘Ok’ and ‘Cancel’ buttons. The ‘Ok’ button is the primary button that completes the action the user initiated. The ‘Cancel’ button is the secondary button that takes users back to their original screen without completing the action. Based on their functions, what is the best order to place them? Should the ‘Ok’ button come before the ‘Cancel’ button or after?

Platform consistency is not good enough

Many have referred to following platform conventions as the answer. While this might seem like a solution to the problem, it really isn’t. It doesn’t answer which placement works better for users and why. The suggestion to follow platform conventions for the sake of consistency is simply not good enough and leaves designers empty-handed.

“Consistency” is a popular word used among designers. It’s also a popular excuse to use to not think deeply about the design problems users face. What’s the benefit of following a design convention, if one doesn’t know why it exists, or if it’s right for users in the first place? What if a certain design convention is harmful to users? Should designers blindly follow it for the sake of consistency? Should bad design practices and lack of design understanding persist because designers want to resort to platform design consistency as the answer to every problem?

There are certain platform design conventions that are widely used today because they work for users. But the point here is that platform design consistency should never satisfy a designer as the sole reason to do something. A true designer needs to understand the problem at a deeper level. And understanding the reasons why you should design your user interface one way, as opposed to another way is key.

Visual weight & labels matter, but so does placement

One could argue that making your action buttons prominent by giving it more visual weight and a clear and distinct label is more important than its placement. While the visual weight and labels of your action buttons are an important design aspect to consider, it’s not the only aspect.

To only focus on one design aspect and not the others is an act of a careless designer. A meticulous designer would think about how every design aspect affects the user. And it’s how primary and secondary actions are placed that is hardest for designers to figure out. That’s why the ‘Ok’/’Cancel’ button debate is such a popular one among designers.

Why ‘Ok’ Buttons work best on the right

When you get past the platform conventions argument, you’ll start to think about which placement truly works best for users. You might say to yourself that user testing is the only way to figure this out. If you’re an inexperienced designer who doesn’t trust your own judgment, then user testing is probably your best bet. But if you’re a knowledgeable and experienced designer who can think about problems from the user’s perspective, then you can solve this problem through design analysis.

Less visual fixations

To analyze this design problem, it’s necessary to see if the common assumptions designers make actually hold up. Some designers believe that putting the primary action on the left side before the secondary action is better for users because it’s closer and, therefore, takes less time to click. This makes sense, but you cannot ignore the fact that users will look at all of their options before they choose which action to take. This means that most users won’t blindly click the primary action button without also looking at the secondary action button next to it. They’ll first see the primary action on the left and then look at the secondary action on the right. Then they’ll move their eyes back to the primary action to click it. This creates a total of three visual fixations in multiple directions.

With the ‘Ok’ button on the left, the visual fixations are more and flow in multiple directions.

With the ‘Ok’ button on the right, the visual fixations are less and flow in one direction.

Compare that with the primary action placed on the right of the dialog box and the secondary action placed on the left. Users start with their eyes on the secondary action, and move their eyes to the primary action to click the button. This creates a total of two visual fixations in one direction, giving users a faster visual flow. Users fixate on each button only once and end on the primary action button. Putting the primary action left might make it easier for users to reach, but when you look at speed in terms of the user’s mental processes and visual fixations, placing the primary action on the right of a dialog box is actually faster.

Maps to the expected button functions

When users click secondary action buttons, they expect the application to do nothing and take them back to their original screen. Thus, ‘Cancel’ buttons function like ‘Back’ buttons. When users click primary action buttons, they expect the application to do the action the button says, and take them forward to the next screen. Thus, ‘Ok’ buttons function like ‘Next’ buttons. Placing the secondary action button on the left and the primary action button on the right maps to the ‘Back’ and ‘Next’ button functions the user can expect.

It’s similar to how pagination buttons are placed. The button that takes users to the next page is on the right, and the button that takes users back to their earlier page is on the left. This button placement works because it maps to the user’s left-to-right reading and navigating direction, where right is the direction to progress and left is the direction to regress.

‘Ok’ progresses users forward to the next screen and ‘Cancel’ regresses users back to their original screen.

‘Ok’ and ‘Cancel’ buttons in dialog boxes should follow a similar interaction pattern because they function like pagination buttons. Not only that, but the left and right directional pattern is what users are used to in the western world. Placing your primary action on the right and secondary action on the left will make your dialog box buttons easier and more intuitive for users to understand.

Gives users a more efficient task flow

A button placed in the bottom right corner of a dialog box is easier for users to click because it follows the Gutenberg diagram. In the Gutenberg diagram, the bottom right area is the terminal area. This is the area where the user’s eyes end up when they finish scanning. Placing your button in this area allows users to see the primary action they need to take last. This not only improves the visual flow, but the task flow as well. Users won’t skip past the primary action button as they’re scanning. Their eyes will land right on it when they’re through, so they can click it right away.

Scanning the dialog box and taking action is fast and easy because the users eyes end on the primary action button.

Place the buttons in the corners, or keep them together?

Another question designers often wonder with dialog box buttons is whether they should place them in the corners or keep them together. When you place your primary and secondary actions in the corners of the dialog box, it maps to the left and right navigating directions really well. However, since ‘Ok’ and ‘Cancel’ buttons aren’t exactly pagination buttons, following the directional mapping rigorously isn’t necessary. In fact, sometimes, it can do more harm than good.

The large visual separation between the buttons makes comparing actions difficult and isolates one action from the other.

If the application is about to carry out a crucial action that the user cannot undo, it’s important that users can see the ‘Cancel’ button along with the ‘Ok’ button. In this case, the ‘Cancel’ button might function like a ‘Previous’ button, but it is more important than it because it acts as a safety button to prevent any changes. The danger of placing the ‘Cancel’ button in the far left corner is that it can cause users to overlook it due to the large visual separation between the two buttons. Putting the ‘Cancel’ button together with the ‘Ok’ button makes it easier for users to see both buttons. This allows users to efficiently compare the two actions in a single gaze to choose the best action to take.

Conclusion

Designers often use dialog boxes when there’s an important message users need to read, or an important action they need to take. The order you place your buttons can affect which action the user chooses. When you place your buttons in an order that is clear and efficient to users, you can prevent them from choosing the wrong action and making a serious mistake.

Button placement is important, but remember to also pay attention to the visual weight and labels you give your buttons. All of these design aspects come into play when users process dialog boxes. Now that you understand the reasons why ‘Ok’ buttons work best on the right, you’ll have something more to refer to when figuring out button placement than the flimsy platform consistency argument.


Others also read:

  • Visual Weight of Primary and Secondary Action Buttons
  • How Button Color Contrast Guides Users to Action
  • Why the ‘Ok’ Button is No Longer Okay
  • When to Use a Button or Link
  • When to Use Toggle Buttons
  • How to Use Arrow and Ellipsis Affordances

anthony

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

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

    Reply to this comment
    • 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.

      Reply to this comment
      • 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.

        Reply to this comment
        • krembo99

          Mar 23rd, 2014

          You can not really read an RTL language from left to right , internet or not . No exception here ..

          Reply to this comment
  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.

    Reply to this comment
    • 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.

      Reply to this comment
      • Yollie

        Feb 19th, 2012

        Remember many people are color blind too.

        Reply to this comment
        • 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.

          Reply to this comment
          • 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”.

    Reply to this comment
    • Senthil Kumar B

      Jun 17th, 2012

      @Nelcon – Well Notiiced

      Reply to this comment
    • 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.

      Reply to this comment
      • 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.

        Reply to this comment
  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

    Reply to this comment
    • 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 ..

      Reply to this comment
      • 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.

        Reply to this comment
      • 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.

        Reply to this comment
    • 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).

      Reply to this comment
    • 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.

      Reply to this comment
      • Nathan Phillip Brink (binki)

        Feb 1st, 2013

        As a previous commenter said, switching around the well-defined order of OK/Cancel buttons is more likely to result in users miss-clicking than placing it “closer” to users. Many users do not even look at the buttons before clicking in the lower right-hand corner (or pressing ‘c’ or ALT-‘c’ or ESC) with the intention of cancelling the action.
        In Windows, the button in the lower-right hand corner of a dialog box is always “No”, “Cancel”, or some other safe non-action.

        Platform consistency matters. Platform inconsistency forces the user to take time to think, like for WinZIP’s “buy me!” popup mentioned above. Users will get frustrated with your product if you consider it special enough to defy the standard UI. If you’re writing in C# on Windows.Forms, _always_ use MessageBox and one of MessageBoxButtons. GTK+ has GtkMessageDialog and GtkButtonsType to help you. “Fixing” the order of the OK/Cancel buttons in a simple dialog box has to be done _in_ the platform itself.

        Reply to this comment
  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.

    Reply to this comment
    • 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.

      Reply to this comment
  6. gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.