| UI or UX | UI + UX - Recovery surface for failed or uncertain background saves | UI + UX - Background-saving form progress | UI + UX - Unpublished object version lifecycle | UI + UX - Scoped failed-operation retry control |
| UI guidance | Show a persistent recovery surface when autosave did not protect the latest work, naming the affected field or section, last server-saved time, local copy status, and available recovery actions. | Render a clear autosave message before users start, then keep a persistent status surface for Pending, Saving, Saved with timestamp, Failed, Retry, and unsafe-to-leave states. | Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions. | Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization. |
| UX guidance | Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy. | Use autosave when losing progress would hurt and background persistence is safer than making users hunt for a distant Save button. | Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version. | Use retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects. |
| Good UI | A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved. | A long application step says the application is saved on every change, shows Saving after an edited title blurs, then shows Draft saved just now with a timestamp. | A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish. | A report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048. |
| Bad UI | A small toast says Could not save and disappears while the form still shows a green Saved label. | A form removes the Save button and shows no save status, leaving users unsure whether typed answers are safe. | An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes. | A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request. |
| Good UX | A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates. | A user writes a long answer, pauses, sees Saving, then sees Draft saved just now and can leave knowing the draft is recoverable. | A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers. | A user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters. |
| Bad UX | A user submits after seeing Saved, but the newest section was failed and never reached the server. | A user leaves after seeing an old saved message, but the newest field was never persisted. | A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list. | The app retries aggressively every second during an outage and makes the service harder to recover. |
| Best fit | Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work. | Users spend meaningful time entering form content or application progress. | Users create or edit objects that should not become visible, active, submitted, or externally effective until a later action. | A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason. |
| Avoid when | The product does not use autosave or local draft persistence. | The form is short enough that a visible manual Save or Submit is clearer. | The change is a small one-field edit that should be saved or canceled immediately. | The error is caused by invalid user input and correction is required. |
| Required state | Clean saved state with current server timestamp. | Initial state that explains progress will be saved automatically. | Published or active state with no draft. | Retryable failed state with affected operation, object, and preserved request context. |
| Accessibility burden | Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt. | Expose autosave status changes in a polite status region so assistive technology users hear Saving, Saved, and Failed states. | Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon. | Use an action label that names the operation, not only an icon or generic phrase. |
| Common misuse | Leaving a green Saved label visible after a failed or stale autosave. | Removing the Save button while providing no autosave status. | Using Saved to mean both saved draft and published content. | Offering Retry for every error regardless of whether the user or system state can change. |