H6.08.1account deletion entry not hiddendesignresearch

Account deletion must not be deliberately hidden

Aliases: delete account entry · roach motel · close account buried

What it is

The deletion entry is the control with which the account holder starts deleting the account. Not deliberately hidden means it lives in the same schema as account management (settings / account / privacy), is searchable by name, and does not require a phone call, a ticket, or an off-app web form merely to begin. This entry is only about whether the flow can be found and opened. It is not about how the flow explains deletion scope, and not about whether export is offered first—those come after entry. Statutory retention, cooling-off, and whether the identifier can be re-registered are post-deletion law and policy, not this page.

Why it happens

Opening an account is under growth pressure; closing it is not, so a “roach motel” appears: in, not out. Hiding includes burying the entry in unrelated depths, offering it only on the web while the app has none, swapping deletion for pause/freeze behind ambiguous words, or forcing a retention questionnaire before the button exists. When people cannot find it, they treat the account as unending, and continued retention is read as consent. Regulators and stores already treat a findable delete as an enforceable duty, not a style choice. Findable is not frictionless: high-consequence actions may still confirm, but confirmation must not be “cannot find.”

Studying it

Give signed-in people “please delete this account” with no path hint; record whether they enter the deletion flow and where they stick.

Independent variables: surface (app and web both present), depth, wording (delete account / deactivate / close), whether a retention page is mandatory first. Dependent variables: found within the first task, mistaking deactivate for deleted, giving up and searching outside guides.

If the lab allows a search engine, the measure is the internet, not the product. Ban outside search or count it as a failed path. “They eventually deleted” is not findability—if the path was emailing support, the entry is still hidden.

Where it stops holding

Accounts that legally need a human check before delete (finance, real-name communities) may execute after review, but starting must still be findable in the app, not ticket-only. Enterprise accounts are deleted by an admin; the personal entry should say “ask your admin,” which is permission, not hiding. An entry that exists only in a delisted old app is hidden from current users. Putting the entry on a marketing site before sign-in, unreachable to people already signed in, is also hiding.

Applying it

  • Put “Delete account” in account or privacy settings on both app and web; settings search for “delete,” “close account,” “erase” should hit the same item.
  • Do not substitute deactivate or freeze for delete; if deactivate exists, place it beside delete and spell the difference; delete must not appear only at the end of deactivate.
  • Retention may appear after the person has tapped delete, and must be skippable; do not make the entry itself a chat with support or a phone number.
  • Verify: people uninvolved in the design, told only “delete this account,” should enter the deletion flow within ten minutes, not deactivate. Walk app and web. If a search engine or a human is required to start, the entry fails.

Related

  • Within the group: H6.08.2 State what will be deleted and by when · H6.08.3 Offer data export before deletion
  • Adjacent: H6.14 Account deletion and data erasure · H6.07 Sign out · H3.06 Friction for destructive actions
  • Search terms: account deletion · roach motel · right to erasure entry

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H6.08.1