So, you’ve released a major re-design to your app. It’s prettier, more functional, and addresses lots of prior complaints. The focus and user testing groups have loved it. It’s all around better.
Then the hate mail starts rolling in.
Why don’t the users see that the new version is better? How do they not recognise you made things easier? Have they suddenly forgotten their complaints?
Major design/interface and architectural changes, while cool and shiny, are fraught with problems for users. The changes usually cannot be transparent as they might be with incremental fixes. Big changes, even for the better, are big changes. And existing users will be thrown by them, even if new users have no issue diving in.
“In most cases, people hate change because they don’t like to suddenly become stupid,” writes User Interface Engineering’s Jared Spool in a 2012 post. Not because they don’t like change, but “because of the changes, you suddenly find yourself unable to do the things you once did. While some are smart enough to blame the designers, most will blame themselves. And those people hate feeling stupid, just like everyone else.”
Sure, user dissatisfaction with change may be a short-term hurdle until new habits are created. However, this tempest puts you in the position of defending your changes to the users, as well as stakeholders who are fielding the negative feedback.
It also costs you time and bias on feedback to the change because they’re already cast in a negative light. As important as developing and delivering a solid product is, it’s just as important to manage the transition.
Says Spool (speaking of Google product change processes): “When the change happens, often the benefits aren’t clear or obvious. Even when they are, (Google’s product team) hasn’t made it clear why the user has to learn how to do everything over again. Sure, there’s new stuff, but was it worth all the hassle of the learning to do the same things a different way.”
Spool posted this 2012 criticism in response to a Google Ventures blog post about its product change methodology. Not only was he right (this issue goes well beyond Google), but he’s become more right since.
These days it’s almost expected that digital applications and services regularly receive major UI overhauls (often coinciding with mobile operating system changes). In most cases, changes are presented fait accompli. Any promotion of the changes is presented in not-terribly-useful marketing-speak.
Of course, even if you do clearly communicate the “whys” in non-self-serving terms, the user’s perception of the hassle being worth the change is going to be subjective. And many users may still find the reasoning lacking. Still, it’s hard to go wrong with being honest with them even when changes are more for you than them.
Major changes require education and lead in – sometimes just letting folks know the cheese will be moved is enough to prepare them for a break in habit. We all aspire to a design so obvious that it requires no tutorial; reality usually falls well below that goal.
Some things you can do to decrease the backlash:
- Let the users know changes are coming well in advance.
- Involve them in user testing and feedback during development.
- Provide a beta test for more feedback and to introduce the changes.
- As launch approaches, make sure you’ve built out solid support documentation and other educational assets for internal support, as well as for the user.
- If possible, provide a link from the current version to the new version during lead up to launch.
- Be clear why the changes were made – for them and for you. Users don’t care that you need revenue to sustain the app, but recognise its necessity.
- Clearly mark information for help in the app.
- When relevant, offer a link to the past version as a fallback.
- Upon launch, have the app/service pop a notice of the change with why and how the change was made.
Yes. I know many – and even most – of the users are going to ignore your messaging and still opt to be surprised by the changes. That’s the nature of things. But over communication here can help ease the transition down the line for the many who do pay attention. While you may not be able to satisfy their pain versus the value, you can help prime them for the changes ahead of time so their changeover is as painless as possible.
We want all our users to be thrilled by changes, but practically speaking, having them more neutral will provide you with better feedback on the pros and cons of your changes for future iterations.
It is just as important for users to have the sense that they’re being heard and developments are being made for them. This can change user attitude immensely.
No one wants to feel stupid.