| 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 | Do not label an action Undo unless the system has captured enough state to restore the affected object, order, relationships, permissions, counts, focus context, and visible outcome. | 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. | 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. |
| UX guidance | Users should trust that activating Undo returns them to the state before the action, not a best-effort approximation that hides what remains changed. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. | Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task. | 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. | Use destructive action confirmation to create one informed stop before permanent or externally visible loss, not to slow every routine cleanup action. | 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 toast says Undo after removing a teammate, but Undo only re-adds the name and not the permissions, group memberships, or notification that already went out. | A tiny x removes an item with no object-specific recovery label. | Five unrelated toasts pile up over the Save and Continue controls. | A trash page lists File 1, File 2, and File 3 with no path, deletion time, owner, or recovery deadline. | A modal says Are you sure? with OK and Cancel after the user clicks Delete, without naming the project or what disappears. | A small toast says Could not save and disappears while the form still shows a green Saved label. |
| 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. | A second delete overwrites the first recoverable item without explaining which action Undo affects. | Every autosave tick triggers a toast, training users to ignore real status changes. | A user restores a shared folder but cannot find it because permissions or parent location changed silently. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | A user submits after seeing Saved, but the newest section was failed and never reached the server. |
| Best fit | Use this anti-pattern entry to audit products that show Undo, Restore, Revert, or rollback controls without proving exact reversal. | 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 | Do not flag a clearly labelled partial recovery, restore-from-trash, request-recovery, or recreate flow as fake undo if it does not claim full reversal. | The action has external side effects that cannot be recalled. | The message is the only recovery path for a blocking or high-consequence failure. | The action is immediately reversible through a short undo window and no durable recovery surface exists. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The product does not use autosave or local draft persistence. |
| Required state | Pre-action state with enough identity, relationship, order, permission, and context captured for reversal. | Normal state before the user action. | Idle state with no visible toast and a reachable status or history region when applicable. | Normal active-object state before deletion. | Idle state where the destructive command is visible but not committed. | Clean saved state with current server timestamp. |
| Accessibility burden | Do not rely on a disappearing visual toast for important recovery; make the control reachable and stable for keyboard and assistive technology users. | Make the undo control keyboard reachable and programmatically identifiable. | Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement. | 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. | Announce failed, local-only, retrying, recovered, and conflict states through status text without repeating every save attempt. |
| Common misuse | Showing Undo after an action that has already sent email, money, permissions, or webhooks outside the product. | Offering undo for an action that cannot actually be reversed. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Showing deleted objects without enough metadata to identify the right item. | Using a vague Are you sure prompt that does not name the object, count, or consequence. | Leaving a green Saved label visible after a failed or stale autosave. |