Recently deleted UX: make recovery clear

Keep enough identity to recognize the missing item

Notik shows a recently deleted note with a title, duration and timestamp beside recovery controls. CraftNote displays a deleted item with a Just deleted cue, Restore and Delete Permanently, plus a retention message. These details help the person distinguish the item they want from a similarly named record.

Preserve useful metadata such as title, thumbnail, source folder and deletion time. The right combination depends on the content. For an audio note, duration can help; for a document, a text preview can distinguish two untitled files. Avoid exposing more sensitive content than the recovery workflow needs, especially in a shared or privacy-sensitive context.

Name Restore separately from Delete permanently and provide accessible labels tied to the item. Do not make two adjacent unlabeled icons carry opposite outcomes. A selected item should remain visible while its action menu is open, so a person can verify the target before confirming a permanent operation.

Separate one-item recovery from collection-wide operations

Knowt exposes Restore and Permanently delete from an item’s trash menu. MyScript shows a trash folder with Select, Delete all and Recover all alongside view choices. Those are different scopes. A person restoring one note should not have to worry that a nearby global action will recover or erase the entire bin.

Keep bulk actions visibly attached to a selection or the whole trash collection. Include the number and, when useful, the kind of items affected. A confirmation should not say Delete these items while the underlying request means every retained item. Update counts when a filter changes and define whether Select all includes only visible results or the complete matching set.

Treat mixed outcomes as a first-class result. Some items may restore while others have expired, lost permissions or failed temporarily. Report the successful count and leave failed items available with reasons and retry where possible. Do not announce All restored if one item remains, and do not repeat already successful restores as new copies during retry.

Use recovery language that predicts the result

Prodrafts labels its recovery action Renew beside Permanently Delete. Smart Cleaner says to tap a photo to restore and also offers Restore all and Delete all. One relies on an unusual action label; the other exposes a direct gesture plus bulk controls. The important question is whether a new user can predict the result before touching the item.

Prefer Restore or Recover when that is the operation. Renew can sound like extending a subscription or resetting a deadline, so it needs clarification if retained. A tap-to-restore interaction should be disclosed near the content and should not conflict with a normal tap-to-preview convention used elsewhere in the app.

If tapping a thumbnail immediately restores it, provide clear feedback naming the item and destination. Avoid removing it from the grid so quickly that the person thinks it vanished permanently. A short confirmation or an Open restored item action can complete the mental model. Preserve the current browsing position when neighboring items shift.

Make the retention policy visible and specific

Craft displays a thirty-day message above retained documents and preserves content previews. AI Cleaner shows a trash size with Empty Trash and Recover All around a thumbnail grid. A retention rule and a storage summary answer different questions: how long recovery remains possible and how much retained material is present.

State when the retention period starts and what expires. If the policy is thirty days after deletion, show an item-level remaining time or deletion date when useful. Do not reset the deadline visually after a device clock change or relaunch. An account-specific or item-specific policy should not be hidden behind a generic banner that makes every item look equally recoverable.

Be careful with storage claims. Moving an item to an app’s trash may not immediately free the same space as permanent deletion. A size estimate should identify what it measures rather than promising device storage recovery without confirmation. If deletion is synchronized, explain when the retained copy is removed across devices and avoid implying that a local empty bin proves every remote copy has disappeared.

Design the empty and expiring states, not only a full bin

Documents shows Recently Deleted with a thirty-day explanation and Selected 0, alongside Put Back, Copy To, Move To and Delete actions. TapNote shows a seven-day message and an item with seven days left, plus Restore and Delete Permanently. These interfaces expose both policy and action vocabulary, but the screen alone does not establish every enabled state.

When the bin is empty, explain that no recoverable items are currently available. Do not imply that the app can retrieve content already permanently removed. If a selection toolbar remains visible with zero selected, make unavailable actions clearly non-actionable and accessible as such. Avoid an active-looking Delete button that only produces an error after being pressed.

For an item near expiry, keep the remaining time consistent with the server’s actual deadline and make restoration available while it is still valid. If expiry occurs while a menu is open, refresh the state and explain the outcome rather than returning a generic failure. Do not pressure users with a countdown that is unrelated to real retention behavior.

Restore the item and its relationships deliberately

Keep a stable item identity through soft deletion and restoration. Record the deletion time, retention deadline and original location according to the product’s data model. Restore should not create a duplicate just because the person repeats a request after a timeout. Return a confirmed result that the interface can use to remove the item from trash and expose its restored destination.

Define a fallback when the original parent no longer exists or the person no longer has access. Offer a suitable destination or restore to a clearly named recovery location rather than silently dropping the item into an unexpected root folder. For shared content, verify authorization again at restore time. Deleting and restoring should not accidentally expand access beyond the applicable sharing rules.

Make permanent deletion a separate operation with a clear scope and an appropriate confirmation. A confirmation can name the item count and explain that the in-app recovery path will end. Do not promise deletion from every backup unless the service’s actual policy supports that wording. Keep the interface honest about retention boundaries without exposing unnecessary implementation details.

Test recovery across time, devices and missing parents

Delete an item, restore it, locate it and open it. Repeat after removing its original folder, changing permissions and reopening on another device. The success condition includes intact content and a discoverable destination, not merely disappearance from Recently Deleted. Check that a restored note retains attachments and metadata required for normal use.

Use fixtures just before and after expiry, a failed network request and a partial bulk result. Confirm that the app does not show an expired item as recoverable indefinitely. If a restore response is lost, repeating the action should reveal the existing restored item rather than create a second copy. Keep failed items selected or otherwise easy to find for retry.

Review keyboard and screen-reader focus after an item leaves the bin. Announce what was restored and where it went. Check large-text action sheets and long file names so permanent deletion is never confused with restoration. A recovery surface should reduce uncertainty at a stressful moment; clipped titles and ambiguous icon-only controls work against that purpose.

Review the full recovery promise

Use these checks on a working build, not only on the polished reference state.

• ✓Soft deletion, archive and permanent deletion have distinct meanings.
• ✓Each retained item has enough identity to verify the target.
• ✓One-item, selected-item and whole-bin actions expose their scope.
• ✓Retention timing matches the actual item deadline and policy.
• ✓Restore explains the destination, including a missing-parent fallback.
• ✓Partial failures preserve failed items and do not duplicate successful restores.
• ✓Empty and expired states do not promise recovery that is no longer available.

Keep recovery distinct from other destructive flows

The account-deletion examples cover a broader account-level decision. Recently Deleted should not imply that account deletion can always be reversed through an ordinary content bin.

Compare mobile error-state examples when designing retry and partial results for a restoration that could not complete.