Persisted state needs a clear-out path
Aliases: clear local data · reset state · forget this device
What it is
What was kept must be take-off-able on purpose. A clear-out path is an action a person can find, understand, and that actually deletes the copy on disk and in the account: clear drafts, clear on-device cache, make sign-out take, forget this machine. Without a path, persistence is a one-way valve — easy in, out only by uninstalling, waiting for expiry, or writing to support.
The path is not “a reset buried in settings”. It has to match the leftover they want to end: on this device, under this account, this one draft. After it runs, the product should behave as if it had never remembered those things — not a surface blank that reappears down another path.
Why it happens
Once persistence works, leftovers grow their own lifetimes: a file on disk, IndexedDB, an OS backup, a push token, a synced copy on another device. A visible “delete draft” that only changes the current view leaves the other lifetimes standing; the leftover will resurrect from backup or sync. So the path’s promise is delete along the lifetime chain, not repaint one frame.
People want the path at a situation change: before handing a phone over, before selling a device, after a demo, after finding an embarrassing search. Those moments have no patience for archaeology. The path has to sit near “about privacy / storage / this document”, in the other party’s words (“forget drafts on this computer”), not in storage-implementation words (“clear localStorage”). Afterward a receipt: what is gone, what the law still keeps, whether they still have to sign out.
Where it stops holding
Records the law requires (transactions, consent, audit) must not be pretend-deleted by this path; say “the bill remains”, do not fake a clear. A cloud object several people share must not become destroyed work for the others because one person cleared — the path must ask “this device” versus “everywhere”. If a miss-tap would destroy a week of unsynced offline labour, confirm must be explicit, briefly undoable, or sync-then-clear. Accessibility preferences wiped can make the product unusable at once; the clear list should tick them separately, not wrap them into “clear all”. An app-store “clear data” is the OS’s path; the product still owes its own, which explains consequences — the OS wipe will not tell you what the cloud still holds.
Applying it
- Offer a findable clear in settings and in the document menu: on-device data, search and drafts, this device’s login. Consequence language, not implementation language.
- Before clearing, state the scope. After, the first glance must show those objects gone, including search suggestions and “continue reading”.
- Separate “this device” from “all devices”; default narrow, so one person does not wipe a household.
- How to check: write a draft and a search term, use the in-product clear, do not uninstall. Reopen: draft and suggestions should be gone. Then look at the same account from another signed-in device: if the on-device clear became a cloud destroy, the scope was too wide. Then deliberately clear only the view and have the substrate write a suggestion back — if it reappears, the path was fake.