PRODUCT NOTE / RECALL · SEPTEMBER 2026
A reminder should keep its promise.
One product decision behind Recall: use deterministic behavior when the user has already made the decision.
- Design rationale
- Based on the current Recall product direction
- Not a report of pilot findings
The request is already clear
If someone asks to revisit a screenshot tomorrow, the product does not need to infer a better time or reinterpret their intention. It needs to preserve the request and make the save available again. In Recall, that is a Return.
An outside check is a different promise
A Watch depends on information beyond the saved image. The system might not be able to complete the check. That calls for a visible next-check window and a distinct failure state. “I checked and found no change” and “I could not check” should never look identical.
The trade-off I accept
Separating Returns and Watches gives users another distinction to learn. I’m choosing that cost because the actions depend on different kinds of reliability. The interface should explain the difference at the moment someone chooses the action.
What would change my mind
If pilot users repeatedly choose the wrong action or cannot explain what they expect to happen, the language or interaction needs to change. The next test is whether people understand the promise and can recover when it fails—not whether they notice the AI.
Read the Recall case study →