UX Design Fundamentals · 16 min · 120 XP
UX writing: labels, errors and empty states
Write labels that say what will happen, errors that say how to fix them, and empty states that say what to do next.
Most interface text is read in under a second by someone trying to get something else done. So the job of UX writing isn't to be clever. It's to make the next action obvious. The words carry more of the design than people expect: a perfectly laid-out dialog with buttons labelled “OK” and “Cancel” can still lead someone to delete the wrong thing.
Buttons say what will happen, as a verb and usually an object: “Delete project”, “Send invoice”, “Save draft”. Generic labels (“OK”, “Yes”, “Submit”, “Continue”) force people to reread the question to work out what they're agreeing to. In a destructive confirmation, the dangerous button should name the danger, so “Delete 14 files” and “Keep files”, not “Yes” and “No”.
✗ Error 4012. ✗ Invalid input. Please try again. ✓ That card has expired. Use a different card, or update the expiry date in Billing.
An error message answers three questions: what happened, why (if it helps), and what to do now. Write in plain language, say it next to the thing that's wrong, and never blame the person (“You entered an invalid date”) when the system could simply say what it needs (“Enter a date like 31/12/2026”). Keep what they typed: clearing a form because one field was wrong turns a small mistake into a big one.
Empty states are a first impression. “No data” on a new user's dashboard is the least helpful possible welcome. Say what will appear here and give the one action that makes it appear: “Your invoices will show up here. Create your first invoice.” And pick one word per concept and keep it everywhere. If it's a “project” in the menu, it isn't a “workspace” in the settings and a “board” in the email.
Don't use placeholder text as a label. Text inside an empty field disappears as soon as someone types, so they can't check what the field wanted. It's also often low-contrast, which makes it hard to read. Put the label above the field and keep any example as hint text that stays visible.
Do it this week: collect every button label and error message from one flow you own into a single list. Rewrite any button that doesn't say what it does, and any error that doesn't say how to fix it.
Loading your workspace…