AI UX Writing: Buttons, Errors and Empty States

AI can produce twenty button labels before a designer has finished explaining the flow. The difficult part is deciding which label accurately describes what the product will do. Microcopy is an interface contract: a short sentence can promise a refund, imply that work is saved, or send someone down the wrong recovery path.

Use generation to widen your options, then narrow them with product facts. A reliable workflow starts with the state of the system, the action available to the user, and the consequences of taking it. Brand voice comes after those constraints, not before them.

Build a state brief before drafting

Give the model a small state brief rather than a screenshot alone. Describe the screen, the user's immediate goal, what has already happened, what the service knows, and which actions are actually supported. A screenshot rarely explains whether a payment failed permanently or is still being processed.

Include technical constraints such as delayed updates, retry limits, unsaved changes, and permissions. Ask the engineer responsible for the flow to confirm them. If an error cannot distinguish an incorrect password from an unknown email address, the copy must not pretend otherwise or accidentally expose account existence.

Specify terminology rules and prohibited promises. Perhaps the product uses “workspace”, never “organisation”, and cannot guarantee recovery within an hour. Give the model a few approved examples. The GOV.UK content design guidance is a useful reference for writing around user needs rather than promotional tone.

Keep personal data out of prompts. Replace actual customer names, addresses, and sensitive support messages with representative placeholders. You need the interaction structure, not the private details that happened to expose a wording problem.

Generate alternatives with explicit trade-offs

Request a small set of alternatives with reasons, not fifty disconnected slogans. Useful dimensions include specificity, length, tone, and recovery clarity. Ask the model to flag any wording that requires a product capability not stated in the brief.

Write microcopy for a failed report export.
Facts: the report remains saved; the download failed;
the user can retry; no completion estimate is available.
Return three options, each with:
Heading, explanatory sentence, primary button, secondary link.
Use plain language. Do not imply data loss or promise a time.
Explain any assumption and keep the action labels distinct.

Treat the response as draft material. A generated “Download again” may be accurate, while “Restore report” falsely suggests the report was lost. Review the implied system behaviour in every noun and verb, including the secondary link that received less attention than the headline.

Use the AI writing tools directory to compare workflows for controlled rewriting, but evaluate the ability to preserve terminology and constraints rather than judging tools by how charming their first output sounds. Keep your approved copy in a versioned source of truth outside the chat.

Make buttons describe the actual action

A button should communicate the next action at the right level of specificity. “Save address” and “Place order” are not interchangeable with “Continue”. Generic labels can be acceptable when adjacent context makes the transition unambiguous, but they become risky around commitments, payments, and destructive operations.

Check action consequences with the implementation. Does “Delete workspace” immediately delete it, open a confirmation, or request an administrator's approval? A label need not narrate every step, but the surrounding text should explain material consequences before the user commits.

Evaluate pairs together. “Cancel” might mean dismissing a dialogue or cancelling a subscription. In a subscription flow, “Keep subscription” can be clearer for the non-destructive option. Do not let AI enforce a mechanical rule that all buttons must have the same number of words.

Test labels in keyboard navigation and with accessible names. The WCAG guidance on label in name explains why visible labels should be reflected in accessible names. Adding a completely different hidden label to compensate for vague visible text creates its own problems for speech input users.

Write errors and empty states around recovery

An error needs enough explanation to support the next step without blaming the user or exposing sensitive internals. Distinguish validation errors, connectivity problems, permission failures, and service outages. Their recovery paths differ, even if a model initially writes “Something went wrong” for all four.

Preserve entered information when the implementation supports it, and say so only when it is true. Identify the affected field, describe an accepted format when useful, and place the message where it can be associated programmatically. The W3C forms notification tutorial covers the relationship between understandable messages and accessible delivery.

Empty states need similar precision. “No results” after filtering is different from an account with no records, a permission restriction, or data that has not loaded. Explain the state and offer a valid next action. Never suggest creating a record to someone whose role cannot create one.

Review recovery continuity across screens. If the error says “Try again”, the retry action must exist and preserve appropriate context. If support is the only route, explain what information to provide without asking users to paste credentials or private financial details into a message.

Test copy in the interface, not a spreadsheet

Place candidate text in realistic components, including narrow layouts, long translations, enlarged text, and loading states. Character counts are useful constraints, but a short phrase can still wrap awkwardly or become ambiguous when separated from its heading. Test meaning and layout together.

Use the contrast checker to verify the foreground and background colours used for error text, helper text, and button labels. This checks a visual prerequisite for reading the copy; it does not evaluate wording, focus behaviour, or whether a screen reader announces an update.

Keep copy acceptance criteria beside each string: triggering state, approved action, relevant accessibility behaviour, and reviewer. Ask a developer to test the actual failure path rather than replacing a screenshot's text manually. Check how dynamic values, plural forms, and localisation keys are assembled.

For uncertain language, observe people attempting representative tasks. Do they predict the correct outcome before clicking? Can they recover without help? Avoid asking only whether they like the wording. The synthetic-user guidance can help generate hypotheses for these sessions, but simulated preferences cannot validate comprehension. After release, review support themes and behavioural signals without assuming that every change in conversion was caused by copy alone.

Key takeaways

• Start with product state and supported actions before asking AI for wording.
• Evaluate button labels against their real consequences and accessible names.
• Give errors an accurate explanation and a usable recovery path.
• Distinguish empty, filtered, restricted, and loading states.
• Validate generated copy in working interfaces and with representative users.