On a dialog box, clicking the ‘Ok’ button means the user wants the system to act. Clicking the ‘Cancel’ button means 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.
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. Common practices accepted in the past are no longer acceptable by today’s design standards. Designers should adopt new design conventions that make the user experience better.
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 ]
Russian translation of this article can be found here: http://habrahabr.ru/blogs/ui/114428/
Could one argue that “Don’t Save” and “Cancel” generate the same outcome and having both is redundant, shouldn’t one be removed?
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.
So what do you think of using “Don’t exist” instead of “Cancel” in this context?
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.
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.
If I click on “Don’t exist” does my application get a transcendentalist experience?
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)’
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.
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.
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?
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.
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
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.
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.
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.
How many UX people does it take to change a lightbulb? I mean, name a button?
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.
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] 🙁
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”.
@anthony
“Your label suggestions are too verbose. Cancel, Don’t Save and Save all say what you’re trying to say more simply and beautifully.”
No they don’t. “Don’t save” violates the exact principle you laid out in this article. “OK” is not an action, but neither is “Don’t save”. “Cancel” is just as generic as “OK”. What am I cancelling, and what will happen after it is cancelled?
Remember that this is one of the most crucial dialog boxes in the world of software, and it has led people to have lost countless documents, because a file was not save before closing.
This is why I am such a fan of cloud documents. There is no “Save” button because the document is automatically saved without asking every few seconds.
Please don’t spell “OK” as “Ok”. This is neither an accepted spelling of the word nor the standard adopted by Microsoft (which users are used to seeing).
https://www.merriam-webster.com/dictionary/OK