System reminders should bind to the triggering context, not just record to-do text

What it is

A to-do list that only stores a line of text ("call back the manager") doesn't automatically give the user what they need to actually get it done — the text preserves the content of the intention, but the real bottleneck in prospective memory is knowing when to think to check that list. For a system reminder to actually work, it needs to be bound to a concrete triggering context — a location, an app state, the moment a preceding step finishes — so the reminder surfaces on its own exactly when the user needs it, instead of waiting passively for the user to remember to open the list.

Why it happens

A plain text list leaves the entire prospective component — reactivating the intention at the right moment — to the user's own internal monitoring, which is no external support at all; the user still has to judge for themselves whether now is a good time to glance at the list. Binding a reminder to context, by contrast, artificially manufactures a perceivable trigger for an intention that previously had no natural cue: the system detects that the user has entered a location, opened an app, or finished a preceding step, and pushes the reminder at that moment. This converts an intention that could only be carried out through self-monitoring into one that can be activated directly by an external cue, sidestepping the exact link — self-monitoring — that fails most often.

Where it stops holding

Context binding requires the system to correctly identify the timing that's actually relevant to the intention — if the bound context is misjudged or defined too broadly (binding "remember an umbrella" to "every time the phone is unlocked" instead of "detected about to leave the residence"), the reminder fires repeatedly at the wrong moments and turns into noise the user learns to ignore or disable, which over time degrades responsiveness to that reminder and to similar ones. Not every intention has a stable context a system can detect in the first place either — a purely subjective intention like "reach out to an old friend when it occurs to me" has no bindable technical cue, so context binding simply doesn't apply to it.

Applying it

• When designing a reminder feature, first define for each category of to-do whether its relevant context is a location, an in-app state, or a preceding action, and only then decide what signal to use to detect that context — don't default to treating every to-do as suited to a fixed-time alert.
• The granularity of the detected context has to match how relevant it actually is to the intention: too broad a definition manufactures a flood of false triggers, too narrow one misses the moments that actually matter — both erode the user's trust in the reminder feature.
• How to check: compare actual completion rates for the same set of to-dos presented as a plain text list versus as context-triggered reminders, and separately track the false-trigger rate of the context-triggered version (the context fires but the user didn't actually need to act on it then); read the two numbers together to judge whether the chosen context was the right one.

Related

• Same group: A6.19.1 Prospective memory means remembering to act at a future time or occasion, distinct from recalling the past · A6.19.2 Event-based prospective memory relies on an external cue; time-based relies on internal monitoring · A6.19.3 Without an explicit reminder, time-based intentions are the ones most likely to be forgotten outright · A6.19.4 Interrupting the current task drains prospective-memory resources, so more frequent interruption raises the odds of a missed to-do
• Nearby: A6.08 Retrieval cues and context dependence · A5.16 Habituation and alert fatigue
• Search terms: context-triggered reminder · event cue · to-do reminder design