DevOps

Yes/No or OK/Cancel on a dialogue?

Should a confirmation dialogue use Yes and No, or OK and Cancel?

Asked on Stack Exchange,

Neither, if a verb will do — and it almost always will. The accepted answer's reasoning is that people do not read dialogue text, so a button reading Yes is meaningless on its own, while one reading Delete or Save still says what it does without the sentence above it.

Why the verb wins

  • A button labelled with the action survives being read out of context, which is how buttons are actually read.
  • Yes and OK only mean something in combination with the message, so they require the message to have been read and understood correctly.
  • Someone familiar with the software wants to scan the buttons and proceed. A verb lets them; Yes does not.
  • Platform interface guidelines were cited in support of preferring a specific action word over a generic acknowledgement.

The failure case that makes the point

One answer supplied the example that settles it. A dialogue asking whether you really want to cancel your account, with buttons marked OK and Cancel, means that OK cancels the account and Cancel does not cancel anything — the word Cancel is doing two opposite jobs in the same box. No amount of careful message-writing rescues that. Buttons reading Close account and Keep account cannot produce the same confusion.

If you must use one of the pairs

  • One answer offered a workable division: a dialogue that asks a question takes Yes and No, while one that performs an action and may take input takes the action word and Cancel.
  • By that rule, Do you want to sign out? gets Yes and No, and Set the event time gets OK and Cancel.
  • The same answer's implicit point is that if you cannot tell which of the two your dialogue is, that is a sign the wording needs fixing before the buttons do.

The underlying assumption

The accepted answer rests on a claim worth stating plainly: nobody reads your dialogue boxes. Whether or not that is literally true, designing as though it is produces better dialogues — shorter messages, unambiguous buttons, and no reliance on the reader having parsed a sentence before choosing. Designing as though people read carefully produces the account-cancellation trap above.