Every question an assistant asks spends a limited resource: your willingness to be interrupted. Ask too rarely and ambiguous notes fossilize; ask too often and the user turns the feature off. The design question is not how to ask—it is when a question earns its cost.
When a question earns its place
The strong cases share two properties: the ambiguity will matter later, and only the author can resolve it.
- An unresolvable referent in a note with likely future use: ‘ask him’—three candidates exist.
- A commitment missing its owner or date: a promise that cannot safely become a task.
- A contradiction with earlier notes: today’s decision reverses last month’s—which stands?
- Media without purpose: a saved photo or link whose reason will be gone in a week.
When silence is correct
Most notes deserve no question at all. Asking about them converts a memory tool into a chore.
- The answer is inferable from existing notes or obvious context.
- The note is low-stakes: a passing thought, a grocery item.
- The user is mid-capture—never interrupt the act of writing or recording.
- The same note has already been asked about once. One question per note.
Never during, rarely after
Timing matters as much as selection. The right moment is a quiet one, soon after capture but never inside it—a gentle queue reviewed when the user chooses, not a popup that hijacks the moment a thought was being saved.
The user trains the threshold
Every dismissed question is feedback that the bar was too low; every answered one confirms it was right. An assistant that does not learn from ignored questions will eventually be ignored entirely.
Ask only what the future will need, only what the author alone knows, only once, and never mid-thought. Every question that fails this test is friction wearing a helpful mask.