Confirmations
Most destructive actions should have a confirmation explaining that the action cannot be reversed and specifying what will be changed.
Confirmation patterns (zeplin)
Esoteric Invalidation
Occasionally an action may be logical but for complex reasons it cannot be performed. For example, it may be logical to delete an item but prohibited due to security reasons or because the item is in a transitional state and cannot be safely removed.
In these events it is appropriate to show a dialog explaining why the action cannot be performed. This is not technically a confirmation, since the user cannot approve the action, but it takes the same general shape and shows up at the same point in the workflow.
Partial-Execution
If an action is only legal for some items, always offer to perform the action but show a dialog explaining what’s going on. For example, “delete” is sensible for a file, but user permissions may prohibit this action for some items.
Rather than hiding or disabling the delete button, allow the user to proceed but explain that the full request can’t be fulfilled.
Destructive Actions
For most delete operations, only a simple confirmation is required.
Some actions can damage large amounts of customer data or cause the system to function incorrectly. In these unusual cases, it is appropriate to ask for further clarification before performing the action.
If the challenge phrase is not supplied or is typed incorrectly, treat this as a normal form validation error. Do not perform the action and mark the challenge field as having an error.