"Users hate change" is one of those phrases that gets repeated until it feels like physics. It's invoked to defend stale interfaces, to justify shipping nothing, and to dismiss negative feedback as temporary noise. But the claim is mostly wrong, and believing it makes for worse products.
What users actually dislike is unexplained change that costs them effort without obvious benefit. Move a button they use forty times a day and you've taxed muscle memory for no reward — of course they're annoyed. The complaint isn't about novelty; it's about a broken contract. They had a working mental model and you rewrote it without telling them.
The evidence is everywhere. People adopt entirely new apps weekly when those apps solve a real problem. They tolerate sweeping redesigns when the payoff is visible within minutes. The backlash to a change tends to be loudest among power users, who are also the smallest and most adaptable segment — they're vocal, not representative, and they usually settle within a week or two.
The practical lesson is to change deliberately and communicate generously. Roll out gradually, offer a temporary way back to the old behavior, and explain why in plain language. When you frame a change as a benefit the user can feel, resistance shrinks dramatically. Treat "users hate change" not as a law but as a warning that you may have changed the wrong thing, or failed to make the case for the right one.