State what will be deleted and by when
Aliases: what gets deleted · erasure deadline · close-account copy
What it is
When someone taps delete they need two facts: which classes of data will disappear from the product (profile, content, sign-in methods, copies shared with others), and by when that is considered done. The explanation sits inside the deletion flow, before confirm, as classes and a deadline—not a link to a long privacy policy. This entry is how the flow’s overall promise is written. The small set that law requires to be kept must be named separately and belongs in another group; here the person must be able to say “ordinary data is gone by when, and the scope is what.” A cooling-off window is retractable waiting, and is not expanded here.
Why it happens
Everyday language treats “delete account” as immediate, total, and unrecoverable. The product is actually an async job across systems and backup cycles, plus copies in other people’s hands. Without scope, people believe chat counterparts also lose history—or, conversely, that a remaining avatar means deletion failed. Without a deadline, they fail to register the next day and think the flow broke, or others still find old profile data before backups rotate. Hiding the explanation in a disclosure under the confirm button is silence: under pressure, people do not expand it. Scope should use recognizable classes (“posts you made,” “your payment methods”), not internal table names.
Studying it
Stop before confirm and ask people to recap disappearing classes and the completion time, against the real policy.
Independent variables: whether the explanation is forced visible before confirm, classes versus legal clauses, a calendar date versus “as soon as possible.” Dependent variables: match between recap and real policy, tickets after deletion from unmet expectations, treating deactivate as already deleted.
Tapping confirm is not understanding. Interviews must split “I thought it was instant” from “I thought their copy vanished too.” Labs make people read unusually carefully; real flows should be judged by what remains on screen if the disclosure stays collapsed.
Where it stops holding
Scope changes with product lines; the explanation must follow services this account actually has. A company-wide template that lists businesses they never used creates panic or false promises. When an hour-precise deadline is impossible, give a cap (“no more than N days”), not “as soon as possible.” Content jointly owned with others (group files, mail already in someone else’s inbox) was never inside “your account”; one sentence should draw that line, or people will think deletion can recall sent mail. Starting the timeline before export has finished leaves people with no copy—export as a prerequisite is the next card; here, simply do not pretend a backup already exists.
Applying it
- Before final confirm, use a full screen or a non-skippable block: classes that will be deleted, ordinary non-statutory items that remain (for example content already public and detached from the account), and a completion cap.
- State the cap in calendar days; after submit, echo “expected done by date” on account status or in email.
- Avoid “everything is wiped immediately”; if the job is queued, say queued.
- Verify: before confirm, people uninvolved in the design write three classes that will vanish and one completion time; against current policy, a missing class or reading the cap as instant fails. After submit, check that the status page still shows the same deadline.