Why the ‘Ok’ Button is No Longer Okay

by on 02/23/11 at 6:20 pm

When the graphical user interface first emerged, designers designed their dialog boxes with a mechanical and binary approach. Clicking the ‘Ok’ button on a dialog box meant that the user wanted the system to act. Clicking the Cancel button on a dialog box meant that the user didn’t want the system to act, and wanted to go back to their original screen. While this was the standard convention with operating systems and applications of the past, most operating systems and applications today have adopted a more user-friendly approach to dialog boxes.

Instead of giving users the Ok button to confirm the action they want to do, it’s more efficient and effective to give users a button that’s labeled with the specific action. ‘Ok’ is not a specific action. It’s an exclamation. When users click the ‘Ok’ button, they’re not just saying okay, they want to do a specific action. The word ‘Ok’ simply doesn’t do the button justice.

An action specific button would better enable users to select the right option quickly nearly every time. Not all users will always read the question or message in the dialog box. Some users will make decisions without reading it carefully or without reading it completely. If your action button is simply labeled ‘Ok’, this could result in a lot of users selecting the wrong option. However, if you label your button with a specific action, it’ll be harder for users to select the wrong option because the action the user wants shows up right on the button. Users will not only be able to select the right option more often, but they’ll be able to do it quicker without needing to read the dialog box message.

This approach lessens user errors and saves the user’s time, especially when the dialog box message is really long or hard to understand. The ‘Ok’ button forces users to not only read the dialog box message, but fully understand it before they can select an option. This isn’t possible for some users who have a language barrier. It’s much safer for those users to select an option based on a simple one word action they’re more likely to understand than a wordy message they’re less likely to understand. One word is also easier to look up in the dictionary if they completely don’t understand what it means.

A good dialog box isn’t just about asking users which action they want to do. It’s also about making each button clear, so that users can select the action they want quickly and accurately every time. The ‘Ok’ button reeks of mediocrity. It’s a button that’s okay, but not great. To get users to interact with your design at a high level, mediocrity simply won’t cut it. What was once popular and accepted in the past, is no longer accepted with today’s design standards. This forces us to grow and change, so that we become better designers as we move into the future.

20 Responses to “Why the ‘Ok’ Button is No Longer Okay”

  1. voidbrain()

    Feb 24th, 2011

    In interfaces, “Ok” was born because they found a misreading problem in the machintosh GUI: the “Do it” action.
    often people did not click the button, when researchers asked them why, they simply replied they did not want to be a “Dolt”.
    [ http://www.folklore.org/StoryView.py?project=Macintosh&story=Do_It.txt ]

  2. zholdas

    Feb 24th, 2011

    Russian translation of this article can be found here: http://habrahabr.ru/blogs/ui/114428/

  3. MonkeyMan8383

    Feb 25th, 2011

    Could one argue that “Don’t Save” and “Cancel” generate the same outcome and having both is redundant, shouldn’t one be removed?

    • anthony

      Feb 25th, 2011

      I guess I should explain the context of this dialog box. This dialog box pops up when you try to close the program. The Cancel button is for a user who wants to do nothing and keep the program opened. The Don’t Save button is for a user who wants to do nothing and close the program.

      • Mateusz F

        Feb 26th, 2011

        So what do you think of using “Don’t exist” instead of “Cancel” in this context?

        • Alexander

          Feb 26th, 2011

          I think a more succinct choice of dialogue would probably be “Quit Application” “Return to Document” and “Save…” instead of “Don’t Save” “Cancel” and “Save…”

          Granted, there might be space or UX issues with those longer button titles, but it would be even more expressive in what’s going to happen when the button is clicked.

          • anthony

            Mar 1st, 2011

            Your label suggestions are too verbose. Cancel, Don’t Save and Save all say what you’re trying to say more simply and beautifully. There’s nothing wrong with the current labels. I have never mistakenly clicked the wrong button or stopped to wonder what each button does. It might be unclear to you because you’re not familiar with the context, but if you did experience it I’m sure you would have no problem with it. Either way, this issue is besides the key point of the article, so enough about that.

        • Kit

          Jul 12th, 2011

          If I click on “Don’t exist” does my application get a transcendentalist experience?

    • crookedspoon

      Mar 1st, 2011

      there’s a difference between ‘don’t save’ and ‘cancel’
      e.g you quit an app, with an open document containing unsaved edits.
      Then the app asks you: ‘do you want to save these changes before quiting’ -> ‘save’, ‘don’t save’ or ‘cancel (quitting)’

  4. Mal

    Feb 28th, 2011

    I do find it sort of interesting that, in my (and other’s) opinions: your criticism of the choices on a dialog box contains a dialogue box that still has some of the same style quirks.

  5. Jon

    Mar 4th, 2011

    I agree with the above comment that the labels should be also reflect what the cancel button will be doing, it’s far to ambiguous. What are you canceling? The save? The exit? Not saving? Something else?

    • Russ

      Sep 5th, 2013

      Old comment, but thought I’d chime in. I disagree. Cancel should do just that… Cancel, no more, no less. Labeling it anything else would not be beneficial, and could possibly even result in confusion. Regardless of why the dialog box has been presented, the cancel button ensures the dialog box goes away and nothing is at risk of being lost or changed. Generally the user knows why the box is on the screen so this is not an issue anyways, but what if my cat walked across my keyboard or I mistyped or pressed something I didn’t mean to and a dialog popped up. I don’t want to have to analyze buttons to make sure I don’t lose any work, I just want to cancel.

  6. Tom

    Apr 13th, 2011

    This is a very interesting article and I fully back the core message you are trying to convey in it. Im having trouble at the moment trying to convince others I work with that “OK” is not sufficient when striving for greater levels of User Experience. With this in mind, I’d very much appreciate a link to a document or a research paper-if you have one-which serves to corroborate the information in this article.

    Thanks

  7. phil jones

    Apr 21st, 2011

    I’m already extremely experienced at seeing the “OK” and “Cancel” buttons. They always look the same and are in the same place on the dialogue box. It takes me no time at all to perceive them and note that they’re there.

    Plus I have a perfectly adequate mental model of driving a computer : “OK means commit to doing this, Cancel means to back out”.

    Why should I have to read and think about “activity specific” labels on buttons? I’ll only get slowed down if I have to read unfamiliar words every time I come across a new dialogue. Plus, as the discussion on “Cancel” vs. “Don’t Save” above shows, there’s often room for confusion when new terminology is invented for specific situations.

    It seems we have a great convention that everyone understands, and breaking it into lots of non-standards is just going to make everyone’s life more difficult.

    • Scott

      Aug 12th, 2011

      You are not understanding this concept. If you are presented with “OK” and “Cancel” you have to read the dialog to know exactly what it is you are okaying. If you quit an application, does the dialog say “Do you want to save your files?” or “Do you want to quit without saving?” You have to read more before clicking OK.

  8. agib

    May 3rd, 2011

    Interesting read, as I’m having the same considerations myself. Which is better, to rely on the OK convention or to spell out the action of button. As Tom, it would be nice to see research results on this topic.

    I can spot a situation, where an OK button is… well, OK: If the message in the dialog box is so long and complex, that you cannot cut it down to a few words fitting a button.

  9. joy

    May 5th, 2011

    How many UX people does it take to change a lightbulb? I mean, name a button?

    • Gary Etterhat

      May 4th, 2012

      Many hundreds of them. But first they have to call a conference to discuss the deep meaning of the OK button. Then they will rewrite the history of computers to fit with their new delusion.

  10. WJ

    Jun 7th, 2011

    I just checked with Microsoft products…. “Save”, “Don’t Save”, and “Cancel” … :-)

    and if we implement by using Win form dialog, we can’t specify the order of the buttons. we can choose only [yes/no], [ok/cancel], [ok] :(

  11. Chris

    Dec 14th, 2011

    I agree that buttons should be labeled with the action the user is taking, but what if the action is to simply acknowledge? Not all dialogs call for an action, some are to just notify a user that something is / has / or will happen in the future.

    I would relate better with a common voice “okay” VS something like “acknowledge”.

Leave a Comment