A Bulk Delete Confirmation Must Show the Set That Will Actually Disappear

A user selects 30 items, changes a filter, and presses Delete. Three items are unauthorized and silently skipped; two hidden items remain selected. “Delete 30 items?” does not describe the actual operation.

Confirm an immutable operation set

requested: 30
authorized: 27
hidden_by_filter: 2
skipped: 3
destructive_now: 27
undo_until: "UTC timestamp"

Enter fullscreen mode Exit fullscreen mode

The confirmation card should name the action, exact authorized count, hidden selections, skipped items and reason categories, retention/undo window, and the post-action destination. Let users inspect the set without losing keyboard position.

Scenario Research question filter changes after selection can users predict included items? mixed permissions do skips look like success? partial API failure is retry scope understandable? undo expires is deadline perceivable without color? screen reader is the set summary reached before Delete?

Stop the study if participants delete unintended fixtures, cannot distinguish skipped from failed, or privacy-sensitive item names appear where they should be summarized. Use synthetic data and a reversible prototype.

After execution, show before/after counts and a stable operation ID. Focus should move to a status heading; Undo must be a real button with its expiry stated in text.

This is a design proposal and research protocol, not validated user evidence. Which is safer for hidden selections: clear them automatically, block deletion, or show an inspectable cross-filter set?