| UI or UX | UI + UX - Anti-pattern where a recovery affordance promises undo but cannot restore the prior state | UX - Post-action recovery behavior | UI + UX - Transient non-modal status message | UI + UX - Durable deleted-object recovery | UI + UX - Final destructive commit review | UI + UX - Recovery surface for failed or uncertain background saves |
| UI guidance | If recovery is partial, delayed, external-effect-limited, permission-limited, or unavailable after a commit boundary, label the action honestly as Restore from trash, Request recovery, Recreate, Retry, or Contact support instead of Undo. | Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region. | Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action. | Show deleted objects in a dedicated trash, recycle bin, deleted-files, or recoverable-items surface with object name, type, original location, deletion date, deleted-by actor, and remaining recovery window. | Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription. | Keep the user's latest local value visible or copyable until recovery succeeds, and distinguish Retry save, Keep local copy, Restore last saved, Compare versions, Download copy, and Continue after recovery. |
| UX guidance | Treat undo as an implementation contract: capture state before commit, block or re-label undo after external side effects, and report restored, expired, failed, partial, and final states separately. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. | Escalate to inline, section, dialog, notification center, undo, or error-state treatment when the message requires repair, proof, long reading time, several actions, or reliable recovery. | Use restore from trash when users may discover a mistaken deletion after leaving the original workflow and need a durable way to recover the object. | Make the safe path explicit and easy, keep the destructive action unavailable until required review is satisfied, and report whether the object was kept, blocked, or permanently committed. | Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy. |
| Good UI | Deleting Quarterly report stores the row ID, folder, owner, sort position, labels, shared access, and selected filter, then Undo restores the row to the same list location. | Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button. | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. | A Deleted files table lists Quarterly budget.xlsx with original folder Finance/Q2, deleted yesterday by Maya, 29 days left, and a Restore to Finance/Q2 action. | Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project. | 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. |
| Bad UI | A bulk archive action offers one Undo button, but a second archive overwrites the first recovery target. | Undo action disappears before users can activate it. | Five unrelated toasts pile up over the Save and Continue controls. | Restore succeeds but the item is invisible because the original parent is gone or access changed. | A soft archive action opens the same severe deletion confirmation used for permanent account closure. | The app clears the field after a failed autosave and offers only Reload page. |
| Good UX | A user archives a task by mistake, activates Undo, and the task returns with its original owner, due date, tags, position, and selection state. | Undo restores the deleted task to the list and reports Quarterly report restored. | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. | A user opens Trash, filters to spreadsheets deleted this week, previews the original folder, restores one file, and gets a link to the restored location. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | 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. |
| Bad UX | A user clicks Undo after deleting a shared file and the file name reappears, but collaborators, comments, and folder path are lost. | The UI promises undo for a side effect that has already notified external recipients. | Every autosave tick triggers a toast, training users to ignore real status changes. | A user expects a file to remain recoverable, but the product hid the retention deadline and the file was purged. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | A stale saved timestamp hides that the latest answer failed after the timestamp. |
| Best fit | Use it when a toast undo, command undo, bulk undo, or keyboard undo may hide partial restoration, expired windows, external effects, or overwritten recovery state. | The action is common and mistakes are likely. | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. | Deleted objects remain recoverable after the user leaves the original workflow. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work. |
| Avoid when | Choose another interaction when the task calls for a different route. | Recovery would restore only part of the user's lost work. | The message is the only recovery path for a blocking or high-consequence failure. | Deletion is permanent, regulated, externally effective, or security-sensitive and should be prevented before commit. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The work is a durable draft object with list-level resume, publish, and discard lifecycle. |
| Required state | Pre-action state with enough identity, relationship, order, permission, and context captured for reversal. | Normal state before the user action. | Stacked state with newest and older messages ordered predictably and capped. | Normal active-object state before deletion. | Review state that names the destructive verb, target object, and affected scope. | Clean saved state with current server timestamp. |
| Accessibility burden | Announce completed, undo available, restored, expired, failed, partial, and final states through status text. | Make the undo control keyboard reachable and programmatically identifiable. | Keep close and action controls keyboard reachable, clearly named, and stable while focused. | Expose deleted item name, type, original location, retention deadline, and restore availability as text in each row. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Place recovery controls in reading order near the affected field, section, or submit action. |
| Common misuse | Showing Undo after an action that has already sent email, money, permissions, or webhooks outside the product. | Restoring only part of the prior state while implying full recovery. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Treating trash as a substitute for confirmation when deletion is severe or externally visible. | Labelling the destructive commit OK, Yes, Continue, or Confirm. | Leaving a green Saved label visible after a failed or stale autosave. |