Every productivity tool has an implied user, and it's someone who turns up.
They open the app most days. They keep the system current. They do the weekly review, they process the inbox, they maintain the structure. Everything works well for that person, and the tools are, in fairness, quite good.
The question nobody designs around is what happens for the other version — the one who vanishes for five weeks in the middle of a hard quarter and comes back to find the whole thing has become a monument to their absence.
What most systems do when you leave
Three things, and each makes returning harder.
They accumulate. Inboxes fill, reviews stack up, the backlog grows. Come back after five weeks and the first task isn't work, it's processing five weeks of arrears, which is an unpleasant afternoon standing between you and anything useful.
They punish. Streaks reset, bars imply lateness, badges are lost. The system's first communication after an absence is a report of what it cost you.
They decay into inaccuracy. The states are stale, the priorities are from a month ago, the next actions refer to a situation that's changed. So returning also means an audit before it means work.
Together those set the price of return, and the price is proportional to how long you were gone. Which is precisely the wrong shape, because the longer someone has been away the less capacity they have for a large re-entry cost.
Designing for the absence instead
The alternative starts from a different assumption: absences are normal, they'll be frequent, some will be long, and the system's main job is to make coming back cheap.
That produces different decisions.
Nothing accumulates. There's no inbox to process, no queue that builds while you're away, no arrears. The state after five weeks is the same state as after five days, only with larger numbers.
Nothing is lost. There's no streak to break, no level to fall from, nothing you have to earn back. The gap counter goes up while you're away and one line sets it to zero, whether the number was four or four hundred.
The system stays truthful without maintenance. Days-since is calculated, not maintained — it can't go stale, because nobody has to update it. A list where the ordering is derived rather than curated is still correct after a month of neglect.
And returning costs one thing. Write a line on one goal. Not a review, not a re-plan, not a catch-up session. A sentence.
The asymmetry that matters
Here's the thing most systems get backwards.
Effort is cheapest to ask for when someone is doing well and most expensive when they're struggling. A weekly review is easy to sustain in a good month and impossible in a bad one — which is exactly when the goals need looking at.
So the design should front-load nothing onto the return. Whatever the system asks of you should be at its smallest at the moment you've been away longest, because that's when you have least to give and when the intervention matters most.
Streaks do the opposite. So do systems built on maintenance, because maintenance debt accumulates precisely during the periods you couldn't maintain it.
You can see the same asymmetry in how people talk about their own systems. Nobody says they abandoned one during a good month. It's always the hard stretch — the illness, the move, the quarter from hell — and the description is nearly always that they fell behind and couldn't face catching up. Falling behind requires a system where behind is a state you can be in, and that's a design choice rather than a fact of life.
What this costs
The honest section, because designing for absence gives up real things.
A system that never nags is a system that can't help someone who won't open it. Notifications are crude and they do work; a tool that waits to be visited will lose to one that shouts at people who genuinely need shouting at. That's a trade rather than a free win.
Accumulating systems accumulate for a reason. An inbox that collects things while you're away is doing a useful job — it's holding items you'd otherwise have lost. A system with no queue asks you to capture things elsewhere, and if you don't, they're gone.
And low-friction returns can enable a particular kind of drift. If coming back always costs one line, and one line clears the number, then a person can maintain a permanently green list while doing nothing of substance. The cheap return is genuinely open to abuse, and the only defence is that the notes read back will show it.
Five weeks in February
He disappears for five weeks. A parent in hospital, then a fortnight of catching up at work, then a week where he simply doesn't open anything.
In his previous system, the return was this: a task manager with 140 items in the inbox, four missed weekly reviews, a streak at zero on two habits, and a set of next actions describing a situation from January. He estimated the catch-up at two hours, didn't have two hours, and didn't return for another month.
Here, the return is: a list of six goals, sorted by gap, the top one at 38 days. Nothing to process. Nothing lost. The states are correct because they were never maintained by hand.
He reads the note on the top goal, written on the last day he touched it: stopped halfway through the costs section, need the Q2 figures. The Q2 figures have been sitting in his inbox for a fortnight.
Eleven minutes, one line written, and the number is at zero. Whether he does more that week is a separate question, and the system has no opinion about it.
What it's optimised for
Not daily use. Not engagement, not time in the app, not the number of consecutive days anyone has managed.
The thing worth optimising is the probability that someone comes back after a long absence, because that's the moment where goals are actually lost. Everything else — the ordering, the notes, the states — is in service of a return being cheap enough to happen.
Which means the app is designed for its worst users, deliberately. If it works for the person who disappears for five weeks in February, it'll work fine for the person who doesn't.
The reverse isn't true, which is the whole argument. A system built for the consistent user works beautifully right up until the first bad month, and then loses them — usually permanently, and usually at the point they most needed it.
Related: The case against streaks · Coming back after six months away · What we left out of goaldrift, and why
Share: