When a green tick briefly appears after “Save”, you want to know what is now complete: is the change stored on the device, saved on the server or already published? Useful system copy answers that question through the actual state, which colour or a cheerful “All done” cannot reliably explain alone.
Derive the message from the state
The right wording follows from the event that triggers the message. “Draft saved” needs confirmed storage, not merely a click on “Save”. Until confirmation arrives, a separate pending state explains that processing is still underway.
When an employee edits an event, feedback for the different states could read as follows:
| State | Possible copy |
|---|---|
| Changes are being sent | Saving your changes. |
| The draft has been saved | Draft saved. The event is not published yet. |
| Publication has been confirmed | The event is published. |
| Saving failed | Your changes could not be saved. Your entries are still here. |
Only use the final assurance if the entries really are retained. Reassuring language must not promise a function the product does not provide.
Explain the next action
An error message is most useful when it makes the next available action clear. A useful retry needs an identifiable route; missing required information needs a link to the relevant field. If the cause is unknown, an explanation such as “Your connection is too slow” would merely be a guess.
Success may need a next step too. After saving a draft, a preview may be useful. A submitted request may require an explanation that a response will follow. State a timeframe only when it applies to the actual process.
Match the tone to the event. Lost input needs a clear explanation and help; it is not a useful place for a joke. Routine saving does not need a large dialog that interrupts work.
Plan visible copy and accessible feedback together
A newly displayed message may go unnoticed by someone using a screenreader. The W3C explanation of Status Messages describes making relevant status changes available to assistive technology without moving focus. Copy and technical implementation belong in the same discussion.
Agree how long a message remains visible, whether it can be found again and whether messages overwrite one another. An important error should not disappear after two seconds while someone is still looking at the field they edited.
Read all messages in the flow together
Reading a task’s button label, pending state, confirmation and failure message together exposes contradictory promises. A “preferred appointment” should not silently become a “booking”, and deleting means something different from archiving. Aligning those terms therefore depends on knowing the actual effect of each action.
This state-and-copy list is working material for a UI and trust refresh. Individual input errors also need a clear association with their field, covered in the guide to form errors and focus.
