https://learn.microsoft.com/en-us/windows-hardware/drivers/i...

> Telephone company executives wondered whether the standard cord, then about three feet long, might be shortened. Mr. Karlin’s staff stole into colleagues’ offices every three days and covertly shortened their phone cords, an inch at time. No one noticed, they found, until the cords had lost an entire foot.

https://www.nytimes.com/2013/02/09/business/john-e-karlin-wh...

The issue I've always found with testing on human users is their willingness to ignore deficiencies.

There is a strong benefit for people "just getting on with it" and "working around" a problem; but it seems like many people are not very good at identifying when a problem is worth solving.

An analogous anecdote I'm aware of was a small in-house call-centre team being moved to digital playbooks (vs those A5 ring bound / tabbed sets). While time-to-resolve each issue got lower and time-to-adapt to new workflows a lot faster, many tracked metrics got worse. Suddenly they were picking up fewer calls, time to answer was increasing, job-satisfaction decreased.

It turns out the new system was forcing the team to be sitting at their desk. In a small and busy multi-team office these people were usually doing all kinds of other small things - be it making coffee, liaising with other teams, etc. - whatever it was they weren't always at their desk. They did have wireless handsets however, so they used to answer the phone, start the call from memory, and move to use the nearest playbook.

The big issue with the digital playbooks was needing to "follow along", you can't reasonably start it away from your desk.

The team knew this was an issue very quickly, it was quite fixable, but they sucked it up for months.