How to Change Software and Don’t Make Your Users Angry

1Ci
1Ci
Aug 31, 2018 · 4 min read

Image credit: Unsplash

Redesigns or major software fixes and updates are often accompanied with a flair of negative comments. Users, who should be thankful to software developers that created tools they use and are working hard to make them better turn angry. But why it is like this, and how to change your product without such problems?

“People do not like change”

It is a common belief that people mostly do not like changes and prefer things to remain the way they have used to. There are lots of psychology research made to bake this theory. Scientists explore people’s preferences and tell us that #1 predictor of happiness is a sense of control.

In this thought framework, it seems obvious that it is almost impossible to introduce any changes in your product in a way that won’t get users angry. You know how to do the product better, but if you change it people will feel they are losing control and have to re-learn everything from the beginning.

No matter product is now really better, customers will go mad. It’s just psychology. So you may decide to better explain changes with beautiful overlays or tutorials so that they understand what elements were moved, and why some features were released while others killed. Seems logical, but the interesting thing here is that in real life it’s just all wrong.

People do not hate change, they hate problems

As Christina Wodtke, UX expert, stated in her brilliant article, “users don’t hate change, they hate you”. If people really hated changes there was no Silicon Valley with its multiple startups and unicorn companies. Google was not first search engine, there were some already, including Altavista. But it turned out to be the best one, so users switched to it. The same with Facebook (remember Friendster, Myspace?) and tons of other successful companies. Users like changes if they make their life better.

Users do not like to feel stupid struggling to find where the Settings menu went after the redesign, how to use this new feature or spend time watching tutorials and skipping overlays with tips that slow down access to the app itself. And when it comes to software, they hate surprises.

Usual scenario for software updates and redesign can be described as a “sudden attack”: the user wakes up, starts his app or program, and realizes that it is just not it was yesterday. Lots of things changed, he or she now needs to re-learn, and there is no information about what benefits it may bring instead.

As a result, users have to spend time on learning, or studying information about changes, and receive negative emotions of such surprises. However, this does not mean they do not like changes as we still have Google, Facebook, Skype, and other products that have proven that changes for the good might be highly appreciated.

Final thoughts: how to implement changes right way

Thankfully, there are a number of best practices to follow working on a major fix or a redesign that will reduce potential negative to a minimum.

  • Fight the uncertainty — people do not want unwelcomed surprises with changes that nobody understands why need to be made.
  • Don’t take control — users should possess control of their software at all times. This means even if you want to introduce something super-duper cool, it is a good idea to give the user an opportunity to not opt-in to these changes.
  • Explain benefits — even if changes are somewhat obligatory, and there is no way you can allow users to remain in their familiar space, spend the time to explain to them how their life will change to the better.
  • Test the update very well — if the new version of a system works bad, this will generate negative even you were good at the announcement and explanation stage.

Our approach

Here is how we organize 1C:Enterprise-based product updates and some of the tools we use.

  • Documentation — we create a full list of needed and upcoming changes and write down what needs to be done for such an upgrade.
  • Compatibility mode — all changes are run in compatibility mode which ensures that platform functionality is restricted to make old code/UX compatible with new features.
  • Version control map and GIT — there should be an opportunity to roll back to the previous version if some problem occurs. This is why we store our code in GIT.
  • Testing — we test everything, including configurations, builds (CI). Code review is performed by several independent developers, tests are both manual and automated.
  • Step-by-step release — before going public and uploading our update we give new version out to a selected group of partners. Only after they’ve used new software and it went smoothly, we initiate the final release.

Written by

1Ci

Build business solutions fast.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade