The filing spot that did not exist at the other office

Seven small mistakes hit us in one sitting while we closed out a file from an office we weren’t in. The filing spot we reached for didn’t exist. A summary was missing the one number we needed to check. A shortened record called a step outstanding when it was already done. A multi-part instruction got garbled inside a quick note. A deletion was refused because a copy was still checked in at a second location. A form needed four hidden fields. And the same approval was requested five separate times. Each one was cheap on its own. Together they made a list worth more than the paperwork.

We didn’t file those seven under “lessons learned” and move on. We wrote each one down as a rule the process should follow from now on, so nobody has to remember to be careful later. Here’s the worksheet, in the order we hit them.

What went wrong	What we used to do	The rule now
We reached for a filing spot that doesn’t exist at this office	Guessed, and the guess was wrong	Ask where things actually go here, every time, instead of assuming it matches the other office
A summary we were handed left out the one number we actually needed to check	Trusted the summary	For anything we’re signing off on, ask for the real number, not someone’s shorthand version of it
A shortened summary told us a step still needed doing. It had already been done	Trusted the shortened version	Check the full record before redoing a step a summary claims is outstanding
We crammed a complicated, multi-part instruction into a quick note instead of giving it its own page, and it garbled halfway through	Kept trying to phrase it more carefully	Anything with more than one part gets its own document
The system refused to let us clear a finished item because a copy of it was still checked in at a second location	Assumed the refusal was a glitch and tried to force it	Clear the copy at every location first. A refusal to delete is often the system protecting you
Nobody told us a form needed four extra fields until after we’d submitted it	Filled in what we could see and hoped	Check for hidden requirements before submitting
We got asked to confirm the same approval five separate times	Answered five separate prompts	One yes covers the whole task. Stop asking again unless something changes

None of these was dramatic. The blank form field cost maybe ninety seconds once we noticed it. The garbled note cost a re-send. The phantom already-done step nearly cost a full re-run of work that was already finished. Strung together in one sitting, seven small costs stopped feeling small.

What each row turned into

A pain you can point at and describe in one sentence is already a written requirement. Every row on that worksheet became either something the process now does for us without being asked, or something it stops and flags before we can make the mistake again.

Only one person was checking this task start to finish, which is why the worksheet mattered. Nobody else was going to notice the phantom already-done step, or that the refused deletion was correct and the system was working as intended. Three weeks from now, tired, doing the same task from a different desk, we won’t remember any of these seven on our own. The worksheet will.

When a manual task goes wrong in several small ways, write each annoyance down as a rule the process follows. Then ask of any recurring task whether it checks for hidden requirements, confirms real numbers instead of summaries, and asks for approval once instead of repeatedly. In the deletion case here, the second copy had to be cleared before the delete would go through.

dxdev LESSON · paste into your AI coding agent
LESSON: Small annoyances stop being small once you write each one down as a rule instead of a memory
SOURCE: dxdev.com/everyday-ai/annoyance-worksheet-turning-one-bad-afternoon-into
WHAT HAPPENED: Closing out paperwork remotely from the wrong office surfaced seven small, individually forgettable frictions in one sitting: a wrong filing-spot guess, a summary missing the one number that mattered, a summary claiming a step still needed doing when it had already been done, a cramped multi-part note that garbled, a delete refusal that turned out to be correct rather than broken, a hidden required field discovered only after submission, and the same approval being re-asked five separate times. Each was converted into a table row: what went wrong, the old habit, and the new rule, so the process itself carries the fix instead of relying on memory the next time.
THE RULE: A string of small, individually-forgivable frictions in one task is worth capturing as explicit rules the moment they happen, because each one is genuinely easy to repeat under fatigue or in a different context. A documented rule is a spec the process can enforce, while a lesson learned that stays only in memory is not.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any repeated operational annoyance, a wrong guess, a stale summary, a redundant confirmation prompt, that has occurred more than once without being converted into a written rule or automated check.
  2. Any workflow step that relies on a shortened or summarized status, such as done or pending, without a way to check the real underlying record when the decision matters.
  3. Any place a system requires the same confirmation or approval to be given more than once for a single unchanged task, rather than accepting one confirmation for the whole scope.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.