Skip to content
design
Foundations

Success messages

Confirm the outcome, say how to undo it, and get out of the way.

On this page
Anchor watch on

Watching from 21:04 UTC with a 45 m swing circle. The drag alarm sounds if the vessel leaves it.

Open anchor watch
VOICE“Anchor watch is on. Swing circle forty-five meters.”
A success message names what is now true, not that something “succeeded”.

A success message confirms that something the crew asked for is done. It states the new situation, says how to undo it when that is possible, and points to the next step if there is one. Then it gets out of the way.

01Name the resultSay what is now true: “Anchor watch on”, not “Success!” The title alone tells the crew what changed.
02Leave a way backIf the action can be undone, say how. An Undo in a toast shows how long it is offered. If it cannot be undone, the confirmation before it should have said so.
03Quiet by defaultMost confirmations are small and disappear on their own. The voice confirms only what the crew asked for by voice.

Anatomy

  • Title (optional): the new state in three or four words. Never "Success" or "Successfully".
  • Body: what is now true, and how to undo it or what comes next. One or two sentences.
  • Action (optional): the next step (Open anchor watch) or Undo.

Voice and tone

Do
Passage plan savedDeparture 06:30 UTC, arrival around 14:30 UTC. It's on the chart and in the log.
Undo
State the new situation in the title, and how to reverse it in the body.
Don't
Success!Your action was completed successfully!
Don't announce success itself. “Success!” tells the crew nothing about what changed.
Do
Log entry saved.
Keep frequent confirmations short. They appear many times a day.
Don't
Awesome work, skipper!Another log entry in the books! You're crushing it today!
Don't celebrate routine actions. An exclamation on every save wears thin by the second day.

Spoken confirmation

When the crew asked by voice, the voice confirms in one short sentence that states the result: "Anchor watch is on." It does not confirm actions taken on screen; the screen already shows the result.

Confirm the persisted result

Show completion after the operation confirms the intended result. A request being accepted or queued needs a pending message, not a saved message: a toast's track(task, { running, done, failed }) shows a spinner while the task runs and turns in place into its result when the task settles. If only part of a task completed, name the completed part and the remaining work. Keep the outcome visible beside a setting when the user needs it to decide what to do next; a short toast can supplement that state.

An Undo action needs a real reversal within its stated limits. In a toast it carries a countdown, the seconds after its label and a bar that shortens, and a deletion is made final in onClose, when Undo leaves the screen. It must not promise to reverse a message already sent or an external action that cannot be recalled. A report's “Completed” label needs the same evidence as a live confirmation.