Capture Friction
The universal advice is to reduce friction: capture in one keystroke, from anywhere, in under three seconds. Every tool competes on it and every guide recommends it.
It is half right, and the half that is wrong produces most of the archives that do not work.
For a workplace-oriented comparison with this kind of workflow, this page provides additional context.
What friction was doing
Filtering. When saving something costs twenty seconds, you save things worth twenty seconds. When it costs one, you save everything, and everything includes a great deal that should not have been saved.
Forcing a decision. The pause is where you notice you cannot say why this matters. Remove it and the noticing does not happen — the note is captured before the question arises.
And producing context. The sentence that makes a note usable later takes twenty seconds and does not survive a workflow optimised to three.
For an independent external reference related to this topic, see Simplenote.
So friction was not purely a cost. It was doing three jobs, and the optimisation removed all three to save seventeen seconds.
Where low friction is genuinely right
Not an argument for making capture hard. Two situations where speed is the correct priority.
When the alternative is losing it. Walking, driving, mid-conversation, half-asleep. Voice capture exists for this and the alternative is not a considered note, it is nothing.
When you are in flow on something else. Interrupting real work to write a proper note costs more than the note is worth. Capture fast, return later.
Both are the same case: the fast version is right when the choice is between rough capture and no capture. It is wrong when the choice is between rough capture and a good one.
The two-speed arrangement
Which resolves the tension, and it is the whole recommendation.
Fast lane. One keystroke, no context, no title. Goes somewhere visibly separate from your notes — an inbox, an unprocessed folder, anything that is not mixed in with the archive.
Slow lane. Twenty seconds: a title that states a claim, and a sentence on why it mattered. This is a note.
And things move from the first to the second on the way out — when something from the inbox turns out to be relevant, that is when it gets processed. Not on a schedule, which is the ceremony that gets abandoned.
Most fast-lane material never moves, and that is correct rather than a backlog. It gets deleted.
The measurement that shows the problem
If you want to know whether your friction is too low, count.
What proportion of what you captured last month could you now say why you captured?
Below about half, and the pipeline is admitting things no decision was made about. That is not a discipline failure; it is a settings problem, and the fix is to add the twenty seconds back for anything going into the archive proper.
The uncomfortable version
Some of the appeal of frictionless capture is that it feels like progress without requiring judgement.
Deciding what matters is work. Saving everything defers the decision to a future self who will have less context and no memory of the moment. The capture bias is exactly this — the pleasant half of a pair, made more pleasant by better tools.
The tools are not at fault for optimising what people ask for. But the advice to minimise friction is advice about one variable in a system with two, and following it faithfully produces an archive that is large, fast to add to, and unusable.
The short version
- Friction was doing three jobs: filtering, forcing a decision, and producing context
- Low friction is right when the choice is between rough capture and no capture at all
- It is wrong when the choice is between rough capture and a good one
- Run two speeds: a fast inbox kept visibly separate, and a twenty-second processed note
- Process on the way out when something becomes relevant, not on a schedule
- Test: what proportion of last month's captures can you now explain? Below half means no decision was being made