Button Label

Putting a button on a screen is easy. Deciding what to write on it was the decision that kept getting pushed to the end, and it usually ended with someone typing "OK" and "Cancel" as the build wrapped up. Those two words seemed to fit every screen, and fitting every screen was exactly the problem.

The dialog that appears before a document is deleted shows why. The line above reads "Are you sure you want to proceed?" and below it sit OK and Cancel. Cancel could mean cancel the deletion or just close the box. OK says nothing about what is being confirmed. The reader has to go back and parse the sentence above, and in a hurry they press one of the two at roughly even odds. Which one they pressed becomes clear only after the document is gone.

Support queues carry a steady trickle of what happens next: I didn't mean to delete that, I didn't know it would charge me. Once teams noticed that changing two words on a button — leaving the screen itself untouched — reduced those tickets, the text on buttons became something to name and manage on its own.

A button label works by showing the outcome in advance. The sentence above it describes the situation; the label names the single action the hand is about to take inside that situation. A well-written one makes sense on its own, without reading the line above. Short strings scattered through a product are called microcopy, and the label is the least forgiving kind, because the result arrives the instant it's pressed.

Four rules cover most cases.

1. Name the outcome as a verb. In a dialog that deletes a document, the button says "Delete," not "OK." A noun alone ("Document deletion") leaves out what changes after the press. The test is whether someone can read the button by itself and predict what the screen looks like a second later.
2. Use the reader's words rather than the product's. If the team has called the feature Export internally for two years, the screen can still say "Save as PDF."
3. Stop at one or two words. "Start your free trial right now" is a sentence, not a button, and long strings wrap or truncate on narrow screens. A label that arrives as "Start your fre…" has lost more meaning than a short one ever would.
4. Two buttons side by side get genuinely different words. "Save" and "Don't save" blur together at a glance. "Save" and "Discard changes" don't.

Anywhere money or deletion is involved, one more rule applies: put the amount or the count inside the label itself. "Pay $22" beats "Pay," and "Delete 3 documents" beats "Delete." A number makes someone who picked the wrong items stop just before pressing.

The first labels worth fixing are the ones in dialogs that confirm an irreversible action — deleting, transferring ownership, cancelling a subscription. Checkout carries the same weight. A label with no amount in it doesn't distinguish paying from moving to the next step.

Sign-up and form submission are places where the label changes the result. The same form converts differently under "Submit" than under "Start for free." Marketing calls that kind of prompt a call to action (CTA). The version on an ad banner exists to get the click; the version inside the product exists so nobody regrets the click.

Buttons on screens that hold no data yet belong here too. The text left on screen when a list is empty is empty state copy, and since that's usually the first screen after sign-up, the button inside it opens the first real use of the product. The same goes for buttons inside an error message. If the message explains the failure and the button says only "OK," there's nothing to do but read and close. "Try again" or "Update card" gives the next step somewhere to go.

Settings screens are the quiet version of the same problem. Nothing is lost when someone toggles the wrong thing, so the labels there tend to go unreviewed for years, and they accumulate internal vocabulary — "Sync scope," "Legacy mode" — that only the team who built the feature can decode. The cost shows up as support tickets asking what an option does rather than as deleted work.

Faint example text inside an input field isn't this. That belongs to placeholder text, which nobody presses.

"This button label just says 'OK' and I can't tell what's being confirmed."

The label only makes sense if you read the sentence above it.

"Can we put the count in the delete button? So people see how many go away."

It's irreversible, so make the reader pause before pressing.

"Let's change only the label to 'Start for free' and compare this week's numbers."

Leave the screen alone and measure what one string is worth.

At Pagedeck this came up when bulk deletion shipped. Noa's first draft had "This cannot be undone" above an OK and a Cancel. Mia pulled up last quarter's support tickets — eleven of them said the deletion wasn't intended — and Noa changed the labels to "Delete 3 documents" and "Keep them." Theo wired the count so it fills in from the current selection.

Two strings changed, but all three of them were in the decision, because a count in the label means the screen has to be holding that number.

The most common mistake is treating labels as decoration applied to a finished screen. The button is already placed and only needs words in it, which makes the assumption easy. But as the count example shows, the label decides what data the screen has to carry, and once the screen is finished the available words shrink to whatever fits the width already drawn. Teams that fill in text last fall back to the short, safe "OK," and the same tickets arrive again next quarter. Writing the labels while the screen is still a sketch costs nothing and changes what the screen has to support.

The other one is reading "keep it short" as a character count contest. The advice is well known, so two words starts to feel better than four. The real test is whether the outcome is visible. If "Delete" shows the outcome, leave it. If it takes "Delete 3 documents," that's the right length. Optimize for brevity alone and you reach the point where the shortest string is also the emptiest.