Designing Small Systems That Survive Interruption
Most real work is interrupted. A small system should assume someone will stop partway, come back later, and still need to understand what is done and what comes next.
May 28, 2026
State should be visible
If you cannot tell what has happened, what is pending, and what is safe to do next, the tool is asking you to remember too much. That works right up until the day you are busy, and then it fails quietly.
Status, history, and the next action belong in the interface. Not in a log file, and not in a mental model that only one person holds.
Resuming should not require trust in memory
The person coming back to a task might be tired, distracted, or returning days later. The next step should be obvious enough that memory helps but is not required.
That matters most where a wrong assumption is expensive: bookkeeping, business records, anything that moves money, and anything where software produced a suggestion that a person is about to act on.
Small systems still need clear transitions
Even a one-person tool has transitions — draft to approved, local record to export, scan to review, suggestion to decision. Those are the moments where work is actually lost.
A good small system makes each of those an explicit part of the product, rather than something the user is expected to remember to do.