Remembering to remember is the part that breaks

There’s a specific kind of forgetting that has nothing to do with a bad memory. You know the plumber’s number. You know you meant to call. You just… didn’t, at the one moment calling was possible, and then the day closed over the intention like water. That’s a failure of prospective memory — memory for things you intend to do later — and it’s the weakest link in the whole memory system. Most of what we build to “help users remember” is really a prosthesis for this one fragile function, and most of it is bolted on wrong.

Psychologists split prospective memory into two kinds, and the split is the whole story. Time-based intentions fire on a clock: call at 3, submit by Friday. Nothing in the world nudges you; you have to keep a background process running that quietly asks “is it time yet?” — and that process is expensive, easily crowded out, and abandoned the moment you get busy. Event-based intentions fire on a cue: when you pass the pharmacy, pick up the prescription; when you open your laptop, answer that email. Here the world does the remembering for you. The cue shows up, and retrieval is close to automatic. Across decades of work (Einstein and McDaniel are the names to start with), event-based beats time-based, and it isn’t close.

So here’s the reframe for anyone shipping notifications: a reminder is you standing in for the user’s prospective memory. The only real question is which kind you’re impersonating. Fire on a clock — “9:00 PM: you have 3 tasks” — and you’ve rebuilt the weak mechanism in software. You interrupt at a moment you chose, not one the world chose, and you ask them to self-initiate an action out of context. Tie the nudge to a cue that already lives in their world — a return to the app, a related action they just took, a place, an event upstream — and you’ve converted a time-based intention into an event-based one. You’ve moved them onto the rails the brain actually succeeds on.

Two rules fall out of the research, and both are easy to get wrong.

First, the cue has to be distinctive and pointed at the intention. A generic buzz that could mean anything is a weak cue; the brain doesn’t route it to a specific action. The best cues are what researchers call focal — they sit right in the path of what the person is already doing, so you can’t process the moment without processing the reminder. A “resume your draft” prompt on the exact screen where drafts live is focal. A digest email listing everything is not.

Second — and this is the one products violate constantly — the reminder has to arrive when the action is possible. A perfectly worded nudge to call the plumber is useless at 9 PM when no one’s answering. Prospective memory doesn’t just need the cue; it needs the cue to coincide with the window where the person can actually act. Fire too early and they defer, which resets the whole fragile chain. Fire when the door is open, and the intention and the opportunity meet in the same instant.

This is different from letting the user plan their own trigger — the “if I’m at my desk, then I’ll do X” move people can form for themselves. That’s their side of the contract. This is your side: designing the reminder system as an external prospective-memory organ and choosing, every single time, whether you’ll lean on the clock or on a cue. The clock is easy to build. That’s why most reminders are time-based. It’s also why most reminders are ignored.

The test I’d apply to any reminder before shipping it: if I strip out the clock entirely, is there still a cue in the user’s world that would make this fire at the right moment? If the answer is no, I haven’t built a reminder. I’ve built an interruption with good intentions.

The science, to look up: prospective memory; event-based vs. time-based intentions (Einstein & McDaniel; Gilbert); the multiprocess framework and “focal” cues; why time-based tasks demand costly, self-initiated monitoring.