Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

People love change. Look how Google, Amazon, and social media took the world by storm. And pocket calculators, smart phones, large screen TV's, the list goes on.

People like changes that benefit them. On the other hand, probably the #1 user request for enterprise software is: Please don't change anything. This tells you something about the software. Common reasons are:

* The last major change broke everything and we couldn't do our jobs for weeks.

* The new system has nobody to help us when there's a problem.

* All of our files / contacts / messages disappeared, or we can't find them any more.

* Meanwhile, we're still expected to keep up the pace of work.



Another way to put it is, people follow the path of least resistance. If they can still make an old thing work, and adopting the new thing seems like a chore, they'll keep the old thing. OTOH, if they see the new thing will greatly ease their life, the path of least resistance is the new thing.

Of course they mostly do this for short-term personal gains. For new solutions that seem like a chore to adopt and only have long-term gains, they won't want to.


Change is painful. It's costly, and comes with risk.

People will embrace it happily, though, when the benefit of doing so clearly exceeds the pain it brings. When you see people resisting change, it's because they don't see that great of a benefit.

This strikes me as a rational position to take.


Don't forget

* The workflow to use your software is so unintuitive I've had to learn it by muscle memory

People don't mind when a nice discoverable UI adds some more features. They don't like it when a horrible poorly thought out one that they had to painfully learn is suddenly different. That button that used to be hidden in the edit menu? Now it's on a ribbon menu which has to be expanded. Good luck hunting!


An interesting lesson is to visit a user site and notice the step-by-step instructions, written out and taped to the sides of monitors, or pinned to cubicle walls. Those instructions were often hard-earned, either written by the user or shared among workers. That stuff becomes obsolete if the software changes. Likewise for online instructions, such as blogs that give instructions in the form of screen captures and text, and that are no longer valid. If the unofficial instructions are better than the official ones, or more legible than the GUI, then it's a step backwards for users.


For enterprise software, people don't like solving a problem twice. Responding to the change doesn't move forward current goals, so any change is bad -- the current problems have been mitigated, so even something that gets rid of the old problems at the expense of needing to to some work to integrate, with uncertainty about new problems is bad.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: