Write Interface Copy That Explains What Happens Next
Worked examples for upload errors, empty states, destructive actions, and uncertain outcomes—not a list of synonyms for “Get started.”
By Design Audit Team · Updated
Write from the actual system behavior
Before changing a button label, establish what the action does. “Publish” is wrong if it only saves a private draft; “Send” is incomplete if the recipient is unclear. Good wording begins with an accurate model of the operation.
For a draft-sharing flow, “Create review link” tells the person what will be produced. Explain who can open the link wherever that access decision is made. Do not substitute an appealing verb for a missing explanation of visibility or commitment.
Replace an opaque error with a usable instruction
Consider this fictional upload response: “Invalid file.” If the product accepts only PDF files, a more useful message is “Upload a PDF file.” If the cause is a size limit, name the actual limit instead. These messages address different failures.
Keep the instruction close to the affected control and preserve other valid input. If the system cannot distinguish a timeout from another service failure, do not confidently blame the file format. The copy should match what the system knows.
Distinguish empty, filtered, and failed states
“Nothing here yet” can be appropriate before the first saved item. It is misleading when items exist but a filter hides them. A service failure is a third condition and should not be written as an empty collection.
Use a specific explanation and an appropriate next action: create the first item, clear or adjust filters, or retry a failed request. An illustration and a friendly tone cannot compensate for sending someone down the wrong recovery path.
Read the action and consequence together
For a destructive action, name what will be removed and explain any important consequence the person cannot infer. “Delete project” is more precise than “Confirm,” but the surrounding copy still needs to reflect what deletion actually affects and whether recovery exists.
Review the whole sequence aloud: invitation, action, pending state, result, and next step. Remove repeated reassurance, unexplained jargon, and statements the implementation cannot guarantee. A small set of accurate words is better than a polished message that promises the wrong outcome.
Review checklist
- Check what the action actually does before naming it.
- Describe the specific cause when the system knows it.
- Write different messages for empty, filtered, and failed states.
- State the real consequence of destructive actions.
- Read the complete sequence, not isolated strings.