SCIFI User Interface Designer Lukasz Wieczorek
Posted on July 20, 2015 by lukasz on design, Interaction Design, UX

Cancel/OK, OK/Cancel or Yes/No?

I’ve recently been in the discussion of which is better Cancel/OK, OK/Cancel or Yes/No. So I did some digging to see if I could find any sources that have already done some research on it. It’s not an easy answer because a lot of people disagree as to the answer. But I think it’s a terrible answer to say “there is no right answer.” So lets try to break it down and get a reasonable non-nihilistic answer.

Nielson Norman Group cites that there are two arguments for the order.

First being that OK should be first due to natural reading order. Also if your user is keyboard driven, well it is obvious you want OK first since it is used more often. [1]

okCancel

 

Second being OK should be last since it ends with the primary choice. It should be approached like a book, right is forward and left is back. [1]

cancelok

What Nielson concluded is that “it doesn’t matter”(though he makes it sound like it does) and you should follow what your main platform is. He says you should spend your resources on more important matters. [1] There is evidence to show even UI/UX community doesn’t have a consensus on this, though it is dated and of a limited sample size. So if it is Windows, you should use “OK/Cancel” and Mac/Android  should be “Cancel/OK”, etc. But either way always stay consistent. I do believe in my heart of hearts it does matter though, because if you are used to a platform and the application has opposite patterns, it will add to all the small papercuts in your application and lead to death by papercuts. So at very least make an education decision based on context. So though it may not be worth doing extensive research on it, we should put our foot down and make a choice one way or the other.

We shouldn’t stop there either because there are many unanswered questions. For example: what about internet applications that work on both. Do we err on the side of windows since it has a majority share? I would take it a step further and say you should actually look at context of the application. If it is a game, like in my case, lets see what the majority of the popular games do.  Also make sure those applications are the majority shareholders.

Now lets touch on the matter of Yes/No vs OK and Cancel, Windows User interface principals has a solid answer:

Instead of Yes/No/Cancel buttons, use texts that clearly state the result of clicking the button, such as “Save File and Exit,” “Exit without saving,” and “Do not exit.” However, stick to the standard Yes/No, OK/Cancel, and such standard buttons whenever possible. Familiarity makes for great productivity. [2]

so In short, don’t use Yes/No unless it is already standardized. Lean on side of explicitly stating intent whenever possible. I’ve seen things like this before:

quit2

When it would have been clearer to use a verb in the place of Yes. In this case “Quit.”quit

I think we should also look at the metaquestion here. There is an inherent need to have someone “approve” or “decline” an action, yeah? Never should be have confirm/confirm or decline/decline. So whether it is a confirmation via  Yes/OK etc, or a reverse action via Cancel/Back/Undo, we should look at the bigger question as well. Confirms should all be on one side and negative or neutral buttons should be on another side. Make sure this pattern is consistent with all your other dialogs.

In conclusion:

  1. Always use verbs when possible instead of OK/Cancel to help eliminate problems.
  2. Always try to be explicit in your buttons with verbs. “Quit” Instead of “Yes”
  3. Always follow examples of other applications in your space you are designing for.

Often, as Lukas(Sweet name bro, but you’re missing a z) Mathis notices, [almost] no one reads your dialog boxes. So we have to make them as quick of a read on the buttons themselves as possible.

Citations:
1. http://www.nngroup.com/articles/ok-cancel-or-cancel-ok/
2.) https://msdn.microsoft.com/en-us/library/windows/desktop/ff728831(v=vs.85).aspx

Leave a Reply