We don’t hate change, we hate changing

My favourite topic of discussion is user experience. User experience is one of those topics that, for the majority of people outside it, means you build a user interface and have abstract thoughts . Not true, but it’s an often shaded area. Recently, I had a conversation with a friend over releasing new versions of software.

“Our customers hate the changes we impose, even when they are good.”

It’s an interesting one, but it makes total sense. If you aren’t careful with the way you impose change on your users, they will hate it regardless. It doesn’t matter about how much time you spend on it, how awesome it looks, how much research you did or how awesome the technology is.

If you don’t deliver changes the right way, people will hate your changes regardless of how great they are.

Now, that’s a bold statement, but let’s look at it closely…

We all have that pair of sneakers (or trainers if you’re from the UK) that we have much love for. They’re old. They probably smell. They’re covered in dirt… but… we love them. We won’t replace them. We won’t seek a change for them.

Your users have the same attachment to your current version of your software as you do to those dirty old trainers. They know that there might be better out there, but those dirty old trainers fit them well. They have grown to adapt, understand and flourish with them.

How do you change without changing

You don’t. Your users will be impacted by your changes, good or great. Your users need to understand your software again, explore, and get used to things that are new. It will take them time to adapt and time to become happy again. But if you can make change a positive, damage-free procedure, your users will continue to be users.

How to make change as comfortable as possible

User testing

Undoubtedly, the majority of the readers here will have user testing. This will include A/B testing, alpha testing, beta testing so on. For the readers that don’t, having your users test your software before releasing it to the general user base not only helps to find bugs in your software, but also brings in early-adopters of the new changes. You can engage with them, understand how long it takes them to get to know your software again, and also make sure that what you are doing is right.

Version switching

Once past user testing, you should impose your changes to the user in the form of an opt-in agreement with the ability to revert changes. Allowing the user to flick between the new and old version can not only let people get comfortable with the new software, but also give them the chance to revert back to the older software if they are not getting on with it. It’s a good place to think of analysing, too, as the adoption rate of the new changes will help you understand if the changes are right.

Incremental Changing

Again, this is something that sometimes works and sometimes doesn’t. It doesn’t fit every circumstance, but it helps your users to adapt slowly. It also helps with the imposition, as imposing mass changes to a user can become confusing. It’s like learning to talk all over again, even if you didn’t agree to it.

And last, but not least (It’s actually probably the most important point):

Always give your users as much time in advance to let them know you are changing. Giving them time to understand your changes will make them feel more comfortable and will make sure they stay a user. Just remember your three year old sneakers.

This is by no means a full list, but more so a quick, 5 minute read that I took away from the conversation. Please feel free to add your thoughts and points.