There has been a lot of discussion in the design world recently about "change aversion." Most of the articles about it seem to be targeting the new Google redesign, but I've certainly seen this same discussion happen at many companies when big changes aren't universally embraced by users.
Change aversion is a real thing. Often people don't like something different just because they're used to the old way. Once they get used to the new way, they discover all the wonderful new features and are happy with the new change.
Change aversion is a real thing. Often people don't like something different just because they're used to the old way. Once they get used to the new way, they discover all the wonderful new features and are happy with the new change.
But sometimes your users' rage isn't change aversion. Sometimes your new design actually sucks.
So, before you blame your users, you should figure out if it's change aversion, or if you really screwed something up. Ask yourself the following questions.
Did You Do Any Sort of User Testing Before Launch?
This is an important one. Sometimes people complain about a product because it has changed. Other times they complain because the product makes them feel stupid or it prevents them from doing what they want to do.
Most often, products make people feel stupid because the products are hard to use.
It's very possible that the changes you made to your product have made common tasks that the user is used to performing harder to do. Yes, the user may eventually learn to perform the tasks the new way, but that new way may be legitimately more difficult! You may even be reducing the amount of time the user spends performing that task, if you make it hard enough.
To pile onto the Gmail redesign for a moment, I can tell you right now that I am constantly hitting the folder button instead of the label button now that they are icons rather than text. I am still occasionally doing this probably a month after I switched to the new look. It's not a deal breaker for me, but it annoys me every time it happens. The new icons, for me, are honestly harder to use than the old buttons, and they build up a certain amount of unhappiness every time I use them incorrectly.
The interesting thing is that this is exactly the kind of problem that you can surface very easily by simply doing some observational testing of people using prototypes or early versions of the product.
Hell, you could probably even figure that one out with metrics. How often are people hitting the Undo button now compared to previously? If people are undoing their actions more frequently, you can bet that your new design is causing them to make mistakes.
Did You Test with Current Users or Just New Ones?
When you have millions of users, it's not cool just to test on people who have never seen your product before.
New user testing gives you really valuable feedback, but it's just one kind of feedback. It doesn't give you any insight into how your current users (often users who are paying you money) are using your product right now.
It may be that your users are doing something surprising with your product. They may be using it in ways you never anticipated. Making major changes without understanding their work styles can destroy something they were relying on.
It's not a matter of their relearning how to do a task in the new interface. You may literally have removed functionality for people who were using your product in innovative ways.
Similarly, if you're only testing with internal users (that is, users internal to your organization), you're not really getting the full idea of how all sorts of different people are interacting with your product. The more types of people you can observe, the clearer your understanding of real use cases and behaviors will be.
Did You Add Something Useful to Users? Really?
Sorry, improving your brand is not particularly useful to users. Even a nice new visual design tends not to be a big enough improvement if you're also changing functionality that users rely on.
Here are some significant improvements that might be enough to counteract a tendency to change aversion:
- making your product noticeably faster or more responsive
- adding a great new feature that users can understand and start enjoying immediately
- fixing several major bugs that people have been complaining about
That's pretty much it.
The problem here is that often companies mistake doing something that is good for the company with something that is good for the user. That can be a tricky thing to spot, but a good way to handle it is to always ask yourself, "What real user problem is this change solving?" If the answer is, "How to give us more money" or "Well, there's more visual breathing space," you might want to brace yourself for the inevitable shitstorm when you launch that change.
Do You Mind Losing a Portion of Your Users?
This is a 100% legitimate question to ask. Sometimes you make changes to your product that you know will piss off a certain subset of your users, and that can be ok.
I've often advocated for prioritizing changes that help your paying customers over changes that help your non-paying users. But there can be other reasons to make changes that annoy certain groups of your users.
The thing is, you have to know that you're making this tradeoff and be ok with it. If you've gone into the change knowing that you might lose a certain percentage of your users, but hoping that you will make up the loss by making other users very happy or attracting new users, that's a fine choice to make. Just be sure that your metrics show this actually happening.
Have You Honestly Listened to Your Users' Complaints?
Let me give you two common examples of user feedback:
- I hate it! It's terrible! I want the old way back!
- I'm constantly hitting the folder button when I want to hit the label button, and I find it really hard to tell which emails are more important any longer. Also, every time I try to Reply to All in the middle of an email thread, it's just ridiculously difficult to do.
Can you spot why they are so different? That's right, one of them is completely non-actionable. There is nothing you can really react to with the first one. You can't fix this user's problem. Yet.
The second one is significantly better because you're starting to get at WHY the user hates the change. You know that the user is having trouble performing specific tasks. You can follow up with the user and have her show you the things that you have made harder to do. You can then figure out if those are things that are done frequently enough and by enough users to justify making them easier to do.
Here's the trick. You can turn the first type of feedback into the second type of feedback by following up with users and asking them for specific things that they hate about your change. If they just keep saying, "It's different!" then they may get over it when they get used to it. But a significant portion of them probably have specific complaints, and writing those complaints off as change aversion is really kind of a dick move.
Have You "Fixed" the Problem by Letting Users Change Settings?
Stop it. Seriously. Just stop it.
The vast majority of your users don't know how to change the default settings.
It's not a failing. They're not stupid. They just don't know nearly as much about your product as you do, so they don't have great understanding of the million different ways you've allowed them to customize their experience. They probably don't even know that those settings are there, and even if they do, why are you making them work that hard?
If you are going to include a few settings that they can change, make them obvious, easy to understand, and don't bury them in a thousand other settings that are incredibly confusing to everyone who isn't in tech and half of us who are.