Why the ‘Ok’ Button is No Longer Okay

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

On a user interface dialog box, clicking the ‘Ok’ button means that the user wants the system to act. Clicking the ‘Cancel’ button means that the user wants to go back to the original screen. While ‘Ok’ buttons were the standard convention with operating systems of the past, most 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 saying “okay”, they’re doing a specific action.

An action specific button would enable users to do their task much more quickly and accurately. Not all users will read the question or message in a dialog box. Most will make decisions without reading it carefully or completely. If an action button is labeled ‘Ok’, this could lead users who ignore dialog box text to click the wrong button. But if you label your ‘Ok’ button with a specific action, users will be able to see what action they’re about to do without reading the dialog box.

Why the Ok Button is No Longer Okay

This approach lessens user errors and saves users’ time, especially when the dialog box message gets lengthy. The ‘Ok’ button forces users to not only read the dialog box message before they can select an option, which is not efficient and not always necessary. Some users who have a language barrier will find lengthy dialog box messages hard to understand. It’s much safer for those users to select an option based on a simple verb 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 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. User interfaces should change and adopt new design conventions that make the user experience better. Designers should grow and learn that common practices accepted in the past, are no longer acceptable by today’s design standards.


Why the Ok Button is No Longer Okay Why the Ok Button is No Longer Okay

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

21 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)’

    • Leonardo Molina

      May 21st, 2014

      Well, MonkeyMan8383, in the case of the prompt to save a document, user can actually take 3 choices: Don’t save the document & close the application, save the document & cancel the close action & continue working with the document. Perhaps the Cancel button could have another label but it makes sense to have 3 buttons.

  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