Microcopy That Works: Button Labels, Error Messages, and Empty States

Small Strings, Large Consequences

Microcopy is the text users actually read. Not your homepage headline, which they skim, but the three words on the button they have to press, the sentence that appears when their upload fails, and the line that shows up when their dashboard is empty. These are the moments where a user either succeeds or gives up.

The pattern in bad microcopy is always the same. The copy describes the system's state, not the user's problem. "Error 500" tells you the server is unhappy. "We could not save your work. Try again in a moment" tells you what happened and what to do. One leaves the user stranded, the other keeps them moving.

What follows are the three places microcopy fails most often, with side-by-side examples you can apply directly. The fixes are not creative writing exercises. They are a consistent way of thinking about who the reader is and what they need in the moment.

Button Labels: Vague vs. Specific

Error Messages That Actually Help

An error message is the worst moment in a user's session, and most interfaces make it worse by sounding like a robot reporting its own failure. The job of an error message is simple: tell the user what went wrong in plain language, and tell them how to fix it. Anything else is noise.

Bad error copy blames the user or hides behind code. "Invalid input" puts the burden entirely on the person who is already frustrated. Good copy names the actual problem and the path forward. "That email is missing an @ sign. Try entering it again." The user knows exactly what to correct.

Tone matters here too. A panicked error message, "Something went terribly wrong!", makes a small glitch feel like a crisis. A calm, factual one keeps the user's confidence intact. Save the personality for the success states, where it belongs.

Error Messages: Before and After

Write an Error Message in Four Moves

1. 1
   Name what went wrong

   Lead with the specific problem, not the word "Error." "Your upload stopped" is better than "Upload error." The user needs to know the nature of the failure before they can fix it.

2. 2
   Say it in plain language

   Drop the technical terms. Users do not know what a 403 is, and they should not have to. Describe the problem the way you would explain it to a friend who is not technical.

3. 3
   Offer the next step

   Every error message should point to an action. "Try again," "Check your connection," or "Contact support" all give the user somewhere to go. An error with no path forward is a dead end.

4. 4
   Keep the tone even

   Do not joke, do not panic, do not over-apologize. A single, calm sentence that states the problem and the fix reads as competent, which is exactly what a frustrated user wants from you.

Empty States Are First Impressions

An empty state is what a user sees the first time they open a feature, before they have created anything. Most teams treat it as an afterthought, leaving a blank screen or the words "No data." That is a wasted opportunity, because the empty state is where you teach the user what the feature is for.

A good empty state does three things. It explains what will go here once the user starts. It shows a clear button to take the first step. And it removes the feeling of staring at a void, which makes users assume the product is broken or that they are in the wrong place.

Think of the empty state as a guided onboarding screen. "You have no saved reports yet. Create your first report in two minutes." is more useful than a blank dashboard with a loading spinner that never resolves.

The Numbers Behind Better Copy