Interface feedback and recovery

A progress bar has stopped. The reader needs to know whether to wait, try again or protect the work already done. Tell them what the application knows, then give the action that knowledge supports.

Interface copy has little space for personality. Its care shows in the distinction it preserves: empty or unreadable, cancelled or complete, accepted or actually finished.

Labels that survive context

Name an action with a short verb phrase: Export font, Choose folder, Try again. Keep the control, accessible label and instructions consistent. Preserve existing labels exactly when documenting them; use sentence case for new house copy.

A text field needs a persistent label. Placeholder text may illustrate a format, but it disappears when the person types. Place required constraints beside the field before submission. Show the accepted number or date format when locale affects interpretation.

Explain a failure

Establish what failed, what happened to the work and which available action can help. State a cause only when the application can identify it.

Fictional example: an export app reports a read-only destination and creates no output file.

Could not export Example.otf. The destination folder is read-only. Choose another folder and export again.

Now change the fact packet: the cause is unknown and the app cannot confirm whether output was created.

Export did not finish. Check the destination folder for Example.otf. If a file is present, inspect it before using it.

The second message is less reassuring because the application knows less. Keep that difference. “Your work is safe” would add a guarantee to both messages. A retry instruction would also need evidence that repeating the operation is appropriate.

Keep diagnostic identifiers available after the explanation. Use a specific title when space permits. Offer a retry only when repeating the operation is a supported remedy, and state any risk of duplicates or partial changes when relevant.

Confirm consequences

Interrupt for a decision that deserves attention. Name the affected item, describe what will change and say whether recovery is available. Put the consequence before the committing action.

Use Replace file for an action that replaces a file. OK leaves the reader to remember the whole dialog. Offer Cancel only if it leaves the pending action undone.

Routine success usually needs a quieter status message. An alert should add information the reader cannot already see.

Report progress honestly

Use a percentage when the application can measure completion meaningfully. Otherwise name the stage: “Preparing glyphs…” or “Writing the font file…”. Show failure when failure is known. Continuing an animation does not make the work continue.

Distinguish Cancel, Stop and Pause by their actual effects. Explain when cancellation must wait for the current item. On completion, name the output and where to find it. Preserve the difference between some items completing and the whole operation succeeding.

Automated conversations

Identify an automated assistant and the tasks it supports. Respond to the person's actual request, keeping the relevant context. Acknowledge unknown answers and uncertain results plainly. A request being accepted does not establish that the action succeeded.

Ask a short question when missing information changes the action. Offer useful choices and allow an answer outside them. Confirm a consequential interpretation when an error could damage work; an already clear request does not need repeated permission.

Describe an actual processing stage rather than inventing a human thought process. Give a real next step or documented support route. Explain how to stop or change an operation when supported, and end when the task is resolved.

Empty states and notifications

An empty collection has been checked. An unreadable collection remains unknown. “No presets yet” and “Presets could not be loaded” must not become interchangeable during editing.

For empty search results, identify the query or filters and offer a useful adjustment if available. For notifications, give enough context to understand the event without opening the application. Avoid repeating an app name already supplied by the system or exposing private content in previews.

Keep lasting instructions in a stable location. A temporary message can point to them.

Permissions and generated content

Name the requested resource and why the feature needs it. Ask in the context of that feature. An explanatory screen must remain distinct from the actual system permission request.

A button that opens the system request can say Continue. Calling it Allow microphone access would imply that the button itself grants access. Let the label describe the step that actually happens.

Signing out, deleting an account, deleting content and cancelling a subscription have separate effects. Explain the relevant effects before commitment; do not imply that one operation performs the others without evidence.

Identify generated content and meaningful limitations. State actual data use when it affects the decision. Offer editing, retry or reversal only when supported. Keep uncertain output visibly distinct from a verified result.

See accessible content and messages and variables for accessible labels, translation context and whole messages.