{"slug":"words-and-labels","meta":{"title":"Words and Labels","slug":"words-and-labels","kind":"grammar","summary":"The text is the interface. A button named after its outcome, a label in the customer's vocabulary and an error that says what to do next do more than any amount of layout.","problem":"Labels get written from the developer's side of the screen — Submit, New, Invalid input, Entity — so the person has to translate every one of them into what it means for them, and sometimes translates wrongly.","family":["orient","act"],"principles":["orientation","friction","consistency"],"status":"stable","visibility":"public","related":[{"title":"Orientation","url":"/patterns/orientation","summary":"Self-explaining labels are half of what makes a screen orienting."},{"title":"Validation Errors","url":"/patterns/validation-errors","summary":"The place where words matter most, and are written worst."}]},"body":"## Buttons are named after outcomes\n\n**\"Save Invoice\" beats \"Submit\". \"Add Customer\" beats \"New\".** The button is\nwhere people learn what will happen, and a verb with no object makes them guess.\n\nThe test: read the button alone, with the rest of the screen covered. If you\ncannot tell what will exist afterwards, it is under-named.\n\nThis applies hardest to the last button in a flow. \"Finish\" tells you the wizard\nis over; \"Create the account\" tells you what you just did.\n\n## Use the customer's vocabulary, not the schema's\n\nIf the business says *job*, the interface says job — even when the table is\n`work_orders`. If they say *matter*, or *load*, or *case*, use that.\n\nVocabulary that has to be translated is vocabulary people get wrong, and the\ncost lands in training, in support, and in the quiet errors where someone picked\nthe wrong thing because two words sounded similar.\n\nCapture the real words during discovery. They are the cheapest source of quality\nin the whole build, and they are free at the start and expensive later.\n\n## Labels stay visible\n\nA placeholder is not a label. It disappears exactly when someone is typing —\nthe moment they most need to check what the field was for — and it fails for\nanyone returning to a half-filled form.\n\nPut the label above the field, keep it there, and use the placeholder for an\n**example of the format** if it earns its place: `PO-2291`, not \"Enter\nreference\".\n\n## Errors say what to do next\n\nThree parts, in order: what happened, why, and what to do.\n\n- ❌ \"Invalid input.\"\n- ❌ \"Error: constraint violation.\"\n- ✅ \"That reference is already used by INV-1039. Use a different one, or open\n  INV-1039.\"\n\nThe second half of a good error is a **path**, not an apology. And an error\nshould never blame the person for a rule they could not have known.\n\n## Empty states and confirmations are copy problems\n\nAn [empty state](/patterns/empty-state) is almost entirely words: which of the\nfour kinds of empty this is, and what to do about it. A confirmation is words\ntoo — \"Delete 43 invoices? This cannot be undone\" is a completely different\ndialog from \"Are you sure?\", and the only difference is the writing.\n\n## The rules worth enforcing\n\n- One term per concept, everywhere. Never *client* on one screen and *customer*\n  on the next.\n- Sentence case for labels and buttons. Title Case reads as a heading and slows\n  scanning.\n- No jargon the customer does not already use — including yours.\n- Numbers in copy, not vagueness: \"43 invoices\", not \"several items\".\n- Never blame the reader: \"That file is too large (12 MB, limit 8 MB)\", not \"You\n  uploaded an invalid file\".\n- Write the error for the person who will hit it at 5pm on a Friday.\n\n## The test\n\nCover every icon, colour and box on the screen and read only the text. If the\nscreen still makes sense — what it is, what is wrong, what to do — the words are\ndoing their job. Most screens fail this, and it is almost always the cheapest\nthing to fix.\n"}