How do you keep a button label short but unambiguous?

You keep a button label short and unambiguous by using a specific action verb tied to the outcome, so the label names exactly what will happen in a word or two rather than relying on generic filler. The method is to trade vague words for precise ones, not to add length, because clarity comes from picking the right verb, not from piling on more words. A label like “Submit” or “OK” is short but tells the user nothing about the result, while a label like “Send invoice” is just as short and tells them precisely what the tap does. Precision and brevity are not in tension; the wrong word is what forces the choice between them.

The reasoning is that a button is a promise about what pressing it will do, and a specific verb keeps that promise where a generic one breaks it. “Submit” describes the mechanical act of submitting, not the consequence, so the user has to infer the outcome from surrounding context that may or may not be clear. A verb that names the outcome, “Save,” “Delete,” “Publish,” “Pay,” collapses that inference into the label itself, so the user knows the result before acting. The “label everything Submit or OK to keep it short” habit mistakes genericness for economy, but a generic label is not actually shorter than a specific one, it is merely emptier, and the emptiness is paid for by the user’s uncertainty at the exact moment of commitment.

Consider a form at the end of a sign-up flow. A button reading “Submit” leaves the user wondering what they are committing to, whether the account is being created, a payment charged, or an email merely sent, and that uncertainty lands at the worst possible moment, right before an irreversible commit. Relabel it “Create account” and the same two-word footprint now states the outcome outright, removing the hesitation entirely. The improvement cost nothing in length; it came from swapping one vague verb for one that names the result. A “Confirm” on a deletion dialog gains the same way by becoming “Delete project,” which is no longer but far clearer about what is about to be lost, and the clarity matters most precisely because the action cannot be taken back. The pattern repeats across the interface: “OK” on a save prompt becomes “Save,” “Submit” on a contact form becomes “Send message,” and each swap trades emptiness for precision at no cost in space.

The exception worth naming is that a label can match the user’s mental model with a noun even when no literal verb fits, since the goal is naming the outcome, not forcing a verb where one reads awkwardly. A pricing card’s “Choose Pro” or a wizard’s “Next step” communicate the result cleanly without a heavy action verb, and that is fine because the user still knows what happens. Context can also carry part of the meaning, so a label sitting under a clear heading may safely shed a word the heading already supplies, as long as the button alone still reads unambiguously when scanned in isolation.

When you write a button label, name the specific outcome with the most precise verb that fits, then stop. Resist defaulting to “Submit,” “OK,” or “Confirm” for the sake of looking tidy, because those words save no space and cost the user clarity. Read each label as if you knew nothing about the screen and ask whether it still tells you what the tap does. Choose the right verb, not more words, and the label stays short while saying exactly what it means.