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.

Toolkits