| UI or UX | UI + UX - Durable deleted-object recovery | UX - Post-action recovery behavior | UI + UX - Final destructive commit review | UI + UX - Unpublished object version lifecycle |
| UI guidance | 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. | 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 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. | 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. |
| UX guidance | 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. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. | Use destructive action confirmation to create one informed stop before permanent or externally visible loss, not to slow every routine cleanup action. | 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. |
| Good UI | 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. | Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button. | 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 knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish. |
| Bad UI | A trash page lists File 1, File 2, and File 3 with no path, deletion time, owner, or recovery deadline. | A tiny x removes an item with no object-specific recovery label. | A modal says Are you sure? with OK and Cancel after the user clicks Delete, without naming the project or what disappears. | An editor opens directly into draft text but the header only says Saved, so users cannot tell whether viewers see the changes. |
| Good UX | 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. | Undo restores the deleted task to the list and reports Quarterly report restored. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | 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. |
| Bad UX | A user restores a shared folder but cannot find it because permissions or parent location changed silently. | A second delete overwrites the first recoverable item without explaining which action Undo affects. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | A user closes an editor after seeing Saved, later discovers the page was never published, and cannot find the draft in the content list. |
| Best fit | Deleted objects remain recoverable after the user leaves the original workflow. | The action is common and mistakes are likely. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | Users create or edit objects that should not become visible, active, submitted, or externally effective until a later action. |
| Avoid when | The action is immediately reversible through a short undo window and no durable recovery surface exists. | The action has external side effects that cannot be recalled. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The change is a small one-field edit that should be saved or canceled immediately. |
| Required state | Normal active-object state before deletion. | Normal state before the user action. | Idle state where the destructive command is visible but not committed. | Published or active state with no draft. |
| Accessibility burden | Expose deleted item name, type, original location, retention deadline, and restore availability as text in each row. | Make the undo control keyboard reachable and programmatically identifiable. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Expose Draft, Published, Unpublished changes, Locked, and Unavailable as text in the page title area and list rows, not only by color or icon. |
| Common misuse | Showing deleted objects without enough metadata to identify the right item. | Offering undo for an action that cannot actually be reversed. | Using a vague Are you sure prompt that does not name the object, count, or consequence. | Using Saved to mean both saved draft and published content. |