Button text should match the action you're confirming

The problem with generic confirmation buttons

You build a confirmation dialog that asks "Delete this page permanently?" and offer two buttons: "OK" and "Cancel." The user has to translate "OK" back into "delete" to verify they're choosing correctly. That translation step costs time and creates doubt.

The button should say what it does. If the action is delete, the button says "Delete." If the action is publish, the button says "Publish." No translation required.

Write the button text as a command

Use the imperative verb from your confirmation question. "Archive this draft?" gets a button labeled "Archive." "Send password reset email?" gets "Send Email." The user reads the question, sees the matching verb on the button, and clicks with confidence.

This isn't about being obvious—it's about removing the cognitive load of matching a generic affirmation to a specific consequence. Error messages need specific recovery instructions, and so do confirmations.

Pair it with a safe secondary action

The secondary button should also be explicit. "Cancel" works when the alternative is returning to the previous state without changes. "Keep Draft" or "Don't Send" work when "Cancel" feels too vague.

Avoid "Yes" and "No" entirely. They force the user to parse the question's grammar to figure out which answer maps to which outcome. "Delete this page? Yes / No" is slower and more error-prone than "Delete this page? Delete Page / Keep Page."

Test by reading the button alone

Cover the confirmation text and read only the button label. If you can't tell what action it performs, rewrite it. "OK" fails this test. "Delete Page" passes.

This applies to destructive actions, publishing workflows, and any confirmation that interrupts the user. The button text is the last thing they read before committing. Make it match the action exactly.