Hidden destructive account deletion

Problem Context

• The product lets users create or authenticate an account that owns personal data, app data, profile data, messages, files, subscriptions, linked apps, child-account data, enterprise memberships, or authentication tokens.
• The deletion route may be hidden in support, legal copy, app-store disclosures, search, account deactivation, data export, privacy settings, or a disabled control.
• Users may attempt deletion after uninstall, while signed into the wrong account, while managing a child or enterprise account, or while a subscription, legal hold, fraud review, or billing dependency is active.
• The organization may be required to provide direct deletion initiation or a trackable erasure request, so the interface must prove that account deletion was reachable and not disguised as another task.

Selection Rules

• Flag this anti-pattern when users can create an account but cannot find a direct account deletion or erasure request path from account settings, app settings, or the required public web resource.
• Flag it when the only visible path is Deactivate, Disable, Sign out, Remove from device, Unsubscribe, Download data, Contact support, or Delete service even though users need account-level deletion.
• Flag it when deletion is visually hidden, delayed by unnecessary screens, searchable only by exact terms, buried below unrelated preferences, or made unavailable after app uninstall.
• Flag it when an account-level destructive action can commit without account identity, affected data, retained data, billing, linked apps, export-first option, recovery window, or request status.
• Use delete account for the corrected account closure and associated data deletion workflow.
• Use destructive action confirmation for one object, subscription, key, file, project, or workspace delete rather than an account and personal-data lifecycle.
• Use typed confirmation as an added wrong-account gate inside a corrected deletion flow, not as a substitute for discoverability or data-scope review.
• Use data export when users need a copy before deletion; export does not itself close the account or erase source data.
• Use privacy settings or settings management when users adjust account controls that keep the account active.

Required States

• Hidden settings state where Delete account is absent or buried behind unrelated privacy/support copy.
• Deactivation-only state where login is disabled but account record and associated data remain.
• Support-only state with no direct request URL, expected timing, identity status, case ID, or receipt.
• Export-confusion state where Download data is presented as if it deletes source data.
• Uninstall trap state where users must reinstall the app to request deletion.
• Wrong-account risk state where deletion does not name the signed-in email, provider, workspace, or child account.
• Low-friction destructive commit state where a small setting row deletes the account without review.
• Retention-hidden state where backups, invoices, fraud logs, public posts, recipient copies, or legal holds are not disclosed.
• Subscription surprise state where billing, app-store renewal, entitlement, or workspace ownership is not handled.
• Corrected discoverable entry state with a direct Delete account path.
• Corrected account-scope review state with account identity, deleted data, retained data, linked apps, billing, export, verification, request status, and recovery window.
• Corrected web deletion resource state that works after uninstall.

Interaction Contract

• Users can reach account deletion from account settings or an equivalent account-control route without needing exact support-search terms.
• A public or web deletion route exists when users may need to request deletion after uninstall or outside the native app.
• The UI never substitutes deactivation, sign out, export, unsubscribe, or remove-from-device for account deletion.
• The destructive account-level review names the exact account before any request is submitted.
• Deletion cannot commit until users can review account data scope, retained data, billing and linked-app effects, verification, and recovery or cancellation limits.
• Support-required deletion states include reason, owner or route, expected timing, status, case ID, and what data will be reviewed.
• Export-before-delete is offered as a separate optional step and does not imply erasure of source data.
• The submitted deletion or erasure request produces durable status, receipt, or notification rather than disappearing into a hidden queue.

Implementation Checklist

• Inventory account creation routes, account settings, app settings, uninstall support paths, public web resources, support queues, data export pages, deactivation controls, and privacy settings.
• Trace whether a user can request deletion from each supported platform and after uninstall without contacting an unrelated support channel.
• Replace hidden, deactivation-only, export-only, or support-only routes with a direct deletion path or a trackable support-required deletion request.
• Show account identity, affected services, associated data, retained data, subscriptions, linked apps, export-first option, verification, typed confirmation, request status, and recovery window before final submission.
• Separate Delete account from Sign out, Remove from device, Delete one service, Unsubscribe, Download data, Disable profile, and Privacy settings.
• Block wrong-account deletion when the signed-in account, provider, workspace, or child-account context changes.
• Test search, mobile navigation, app uninstall, web deletion URL, multiple accounts, child account, enterprise-managed account, billing owner, legal hold, pending request, failed support case, and compact layouts.

Common Generated-UI Mistakes

• Hiding account deletion in a privacy policy, FAQ, support article, or exact-match help search.
• Offering only deactivation and keeping account data active.
• Presenting data export as the end of the account deletion process.
• Requiring users to email support with no identity check, expected response time, request ID, or status.
• Removing Delete account from the app after users uninstall or sign out.
• Using a small settings-row toggle or vague Delete button for account-level destruction.
• Omitting retained-data, subscription, linked-app, child-account, enterprise-policy, or wrong-account consequences.

Critique Questions

• Can users find account deletion from account settings without searching help?
• Can users request deletion after uninstall or outside the native app when needed?
• Is the visible route truly account deletion, or only deactivation, export, unsubscribe, sign out, or support contact?
• What exact account, provider, workspace, or child account would be closed?
• Which associated data is deleted, retained, transferred, public, backed up, or outside the product's control?
• Does the flow produce a request ID, status, receipt, or completion proof?
• Is this the hidden account-deletion anti-pattern, or should the corrected route be delete account, destructive action confirmation, typed confirmation, data export, privacy settings, or settings management?