Write UI Copy: Buttons, Empty States, and Error Messages
UI copy is not decoration. When someone is stuck, the sentence they read is often the only help they get. This workflow writes by state instead of by inspiration.
How to do it
Step 1: List every place the interface speaks
Start with “Empty-State and Error Copy” per page: have it list what each of the five cases must answer — first use, no results after filtering, failure with retry, no permission, network loss. Then add loading, success, and over-limit yourself. For every state, write one line on what the user knows and what they can do; any state you skip gets filled in by an engineer at the last minute.
Step 2: Draft with “Empty-State and Error Copy”
Ask for three things per state: one sentence of explanation, one action, and one fallback. An error must say whose problem it is, whether retrying helps, and what to do if it still fails. Do not ship “Something went wrong”; it tells the user nothing.
Step 3: Fill the in-between states with “From empty state to content”
First use, generating, partially complete: these middle states get skipped most often. Tell people the progress, roughly how long it takes, and whether they can leave the screen. A lone spinner makes people refresh and start over, which only makes it slower.
Step 4: Set a baseline with “One paragraph, three tones”
Write the same line in three tones: neutral, friendly, restrained. Pick one as the baseline and check the rest of the product against it. If the brand is formal, drop exclamation marks and internet slang. Two tones on one screen do more damage than plain wording.
Step 5: Rewrite for each audience with “Rewrite the same content for different readers”
For the same error, a new user needs to know what happened and what to do now. A returning user or an admin also needs the scope of impact and the follow-up. Keep both versions in the copy sheet instead of asking one sentence to serve everyone.
Prompts used
FAQ
Should a button say “OK” or a specific verb?
Use the specific verb. “Save changes” predicts the result better than “OK”. Reserve “OK” for the rare case where the outcome genuinely cannot be predicted.
Should error messages show an error code?
Show plain language first and put the code in expandable details or the logs. Support needs to find it; the first thing a user sees should not be “ERR_5003”.
Does an empty state need an illustration?
Not necessarily. First make one sentence say what this place is, why it is empty, and what to do next. An illustration is a bonus; a missing explanation is the actual defect.