When product memory becomes surveillance
Products that remember things feel thoughtful. Your draft is still there after a refresh, your filter is still applied and you land back in the file you were editing.
But the same memory can feel invasive. A private search reappears on a shared computer the next day, or a draft you deliberately abandoned keeps coming back every time you open the app.
Nothing about the storage changed between those two experiences. What changed is whether you could tell what would come back, where it was kept and how to remove it.
So product memory is less about how much context to keep and more about the contract around it: what’s remembered, for how long, on whose device or account, and under whose control. Here’s how I’d think that contract through.
Why “remember everything” goes wrong
Persistent context has obvious benefits. If a product stores more history, it can offer more continuity:
Forgotten context creates friction; a user rebuilding a complex filter after refreshing may feel the product is careless. A person who loses a long draft may lose trust immediately. The problem is that not all context carries the same sensitivity. Remembering a display preference is different from remembering a private search or resurfacing a document on a shared device. “Remember everything” turns a convenience feature into a retention policy.
What is the user allowing us to keep?
Product memory is a claim about the user relationship; when a system stores context, it decides:
Those choices go beyond implementation, because they determine whether continuity feels like assistance or surveillance.
The first category can often be useful by default when it is visible and local to the task. The second needs a clearer contract.
Keep context, not surveillance
The most useful memory is often narrow and immediate.
These forms of memory help the user continue work they visibly started. The relationship between action and recall is local and understandable.
The risk increases when memory crosses contexts without warning: a private search returns weeks later, an abandoned workflow keeps resurfacing, or another person's context appears on a shared device.
“Keep context where the user expects continuity; ask before turning that context into a lasting profile of them.”
Visibility is part of trust
A product should not make people guess what it knows; if the system restores a draft, say so:
If it retains a filter:
If it stores a preference:
The wording does not need to be intrusive, but it does need to make the relationship visible. Trust comes from making memory legible.
Why a clear-all button is not enough
A global clear-all option can be useful for account deletion or privacy controls. It is not enough for day-to-day control.
Local controls reduce the cost of correcting the product, and they also provide feedback: if users repeatedly discard one kind of remembered context, it may be resurfacing at the wrong time. A memory feature should be easy to reverse.
Expiry is a feature
Infinite retention is often an accident. Something is stored for restoration, but no expiry is set because the immediate task is not framed as retention. A useful memory policy asks:
A draft may remain until it is completed or discarded; a temporary filter may last for one session. A sensitive search may deserve no persistence; a user preference may remain until explicitly changed.
Expiry makes a product intentional rather than forgetful.
Shared devices and account boundaries matter
Memory becomes risky when assumptions about one person and one device are wrong. A shared computer, workplace browser profile, or borrowed device can reveal context through recent searches, drafts, contacts, records, autofill, and filters. The product should decide whether remembered context belongs to an account, device, browser session, or workspace.
Choosing the wrong scope can create a privacy problem even when the feature works technically.
The system should not infer more than it needs
A product can create memory without explicitly storing a memory object. Search history, event logs, recommendation inputs, analytics data, browser storage, cached responses, and support tooling can retain fragments of user context. Data minimisation is therefore a product design principle:
Less retained state means fewer privacy risks, fewer confusing recall behaviours, and fewer difficult deletion or access requests later.
Final thoughts
Memory can make a product feel attentive, and it can also make a product feel as though it has been watching too closely. The difference lies in the contract with the user rather than the sophistication of the technology. Remember context when continuity is clearly useful, make retained information visible, give people local control to remove it, set expiry deliberately and keep sensitive state narrow and scoped. A product should remember enough to help someone continue their work. It should not remember so much that the user has to wonder what else it knows.