Change Aversion And The Conflicted User
Written by Roxanne Abercrombie
Change aversion, much like change itself, is a divisive topic.
One camp asserts that users hate change. Software users have “baby duck syndrome” — imprinting on the first system they learn and judging later iterations by their similarity to the first. When a product is changed, then, users dislike it almost on principle.
For the other camp, change aversion is a term thrown around by designers reluctant to accept that their changes might have impeded usability or productivity. Rather than hating change, users hate bad design. If your userbase rebels against your update, the blame lies with the update and not with those lumped with it.
There is truth in both sides of the argument. Change can be a chore, and users will always react to updates to your product. Your actions, however, sway whether they respond positively or negatively. So, how can you manage change to mitigate aversion?
The Four Categories Of Change
First, it is essential to understand the types of change users navigate over the course of a product lifespan.
According to Florian Deißenböck, there are four main reasons that businesses change their products:
- To correct — Corrective change
- To adapt — Adaptive change
- To prevent — Preventive change
- To perfect — Perfective change
Not all these categories trigger change aversion. Some, in fact, are near-invisible to the end user.
1. Corrective Change
Corrective changes are unglamorous but essential. They address bugs and flaws in the software product and are usually small, swift changes. Think regular software updates, rather than upgrades.
A corrective change is unlikely to invoke user annoyance. After all, they solve known glitches and improve overall reliability. (Although, as this comic amusingly points out, even corrective changes can be unwelcome for users grown accustomed to a long-standing bug.)
2. Adaptive Change
Adaptive changes focus on infrastructure and the environment. An adaptive change might respond to an update in an operating system, or a platform or hardware change.
Typically, adaptive changes to a software product improve speed and scalability. As such, their impact is relatively subtle and likely to be low-impact for the average end user.
3. Preventive Change
Preventive changes exist to futureproof a product. They help prepare for prospective, long-term changes, making sure that the product is maintainable and malleable.
This type of change often manifests as refactored code or updated documentation. This means the user might not always see preventive changes at work outside of the ongoing stability they enjoy.
4. Perfective Change
Perfective changes are usually at the heart of change aversion. With perfective changes, the user sees the most tangible differences within a product, its features, and its interface.
These changes address functionality — meaning new features to get to grips with, existing features tweaked, and some features scrapped altogether. They also extend into usability, resulting in interface amends and redesigns. Naturally, this type of noticeable change is the most likely to trigger confusion and annoyance.
Understanding Change Aversion
Despite the user commotion they can cause, perfective changes are a fundamental (and frequent) aspect of software product maintenance. Their goal, after all, is to perfect; to make the product more useful, usable, and enjoyable. Unfortunately, the user may not always be onboard.
There are many reasons users react adversely to changes, and most are more rational than sentimental.
Resource Drain
Users have spent time and effort learning to use your software system. They know its ins and outs, their set-up is finely-tuned, and they can navigate menus and features without pause for thought. Habit, as William James writes, is an enormous flywheel. For users, any forced changes to established habits cause disruption.
Change renders users suddenly stupid. They have to relearn procedures that were previously effortless; waste time hesitating over new and unclear options. As well as being a resource drain, this can feel like an affront to loyal users who are now alienated from the very product they recently excelled in.
Experience Rot
Experience rot is a result of breaking, burying, or modifying functionality that the user relied on. In some cases, you might have removed functionality altogether.
The user suffers because they can no longer achieve their goals as smoothly and efficiently as they did before. The goodwill that users felt rapidly mutates into frustration. This is exacerbated if the user perceives no value in your tinkering — why would you mess with something they liked and needed?
Productivity Plunge
Frustration, feature loss, and re-learning all lead to an inevitable productivity plunge. Your product is supposed to save the user time — not cast them into confusion.
Even if a decline in productivity is only temporary, it still represents an inconvenience for the user. Their return on investment is diminished; their output impeded. When the technology you rely on suddenly forces you into inefficiency, through no fault of your own, change aversion is a natural reaction.
Legacy Love
Legacy attachment may be a sentimental driver of change aversion, but it feels no less valid to the user. Familiarity breeding liking is a proven phenomenon referred to as the mere exposure effect. When a product changes, it can offend our nostalgic sentiments — even if the changes are ultimately beneficial.
We look back with affection at old products and their clunky designs. (Indeed, there is a growing market catering to nostalgia-driven re-releases.) The lesson is clear: users feel fondly towards legacy systems, and newer releases often compare unfavourably to a sentimental eye.
Mitigating Change Aversion
Change aversion, then, is more than unreasonable pitchfork-waving. It stems from a complex medley of emotions and rationalities and should be handled with due consideration. Fortunately, there are several actions you can take to mitigate adverse user reactions to change.
Change Little and Often
Too much change too fast is bound to give your users digital whiplash. Studies have highlighted that change can degrade user performance, and requires a meticulous change management strategy. So, plan changes incrementally.
Rather than pushing out a new design or new feature-set in one major release, break your changes up into manageable bite sizes that users can digest easily. It might be a colour change one week, or a rounded button the week after. By changing gradually, you avoid user shock and perceived re-learning effort.
Use a Product Roadmap
To achieve this kind of consistent, agile update process, you need a clear product roadmap in place. You should know what you are changing and why; what your goal is with each iteration. Some changes, of course, will be reactive and difficult to plan in advance. However, anything regarding interface and feature changes can be (and indeed should be) carefully planned.
Communicate in Advance
Clear communication is imperative for mitigating change aversion. Offloading unexpected changes onto unprepared users is plain poor form, and will catch them off-guard. As a result, they will already be more likely to take a defensive or indignant stance.
So, inform users if you plan on making significant changes to their product. When doing so, be sure to explain the benefits of the changes headed their way. Users are using your service for the value it adds, and any added value is welcome.
Be Flexible Between Versions
In the words of Aaron Sedley: “Allow users to play in the new sandbox before removing the old one.” You could offer a preview of the new-look product with a beta version. You could integrate placeholders for pending features into your existing product, to manage their expectations. Best of all, you could allow users to toggle between the new and old versions of the product. The point is: you should offer flexibility to give the user more control over changes.
Provide Ongoing Support
Supporting a new release goes beyond updating your help files. You should strive for the smoothest possible transitions between software versions — and that entails providing upgrade instructions (where relevant), in-app help and announcements, video tutorials, demonstrative GIFs, and human support when sought.
Listen to Feedback
You might think your changes make for a superior product. Do your users feel the same? The proof of the product is in the using, and your users are giving you that proof with every piece of their feedback and every in-app behaviour. You would do well to pay attention.
It might be a product survey. It might be a dedicated feedback forum or a dedicated area within the product in which users can submit their comments. Whichever avenue you choose, you need to collect and actively listen to real user feedback. For any users still averse to change, feedback outlets provide an opportunity both to vent and to have their concerns addressed.
Keep Testing
Testing goes hand-in-hand with feedback. This includes user testing as well as eating your own dog food — or using your own product internally. If you still find that user attitudes remain negative after a reasonable readjustment period, it might be time to reconsider your design and feature choices.
Smoothly Does It
Change aversion is real, with more than valid roots. However, its reality does not mean that change aversion has to be realised with every update you push out. Jared Spool writes that: “When we proclaim: ‘Users hate change and there’s nothing we can do about that’, we’re removing the requirement to provide a quality experience for our users.”
You can — and must — manage change effectively, rather than brushing aversion off as inevitable griping. Naturally, when change feels hostile for the user, the blame lies on you for poor change management. If they stick with your product for any length of time, your users will experience change. How you manage that change determines whether the user feels turbulence or a smooth path towards constant progress.
Want to learn more?
If you’d like to become an expert in UX Design, Design Thinking, UI Design, or another related design topic, then consider to take an online UX course from the Interaction Design Foundation. For example, Design Thinking, Become a UX Designer from Scratch, Conducting Usability Testing or User Research — Methods and Best Practices. Good luck on your learning journey!
(Lead image: Depositphotos)
Originally published at UsabilityGeek by Roxanne Abercrombie, who is an Online Content Manager at Parker Software — a UK-based software house specialising in live chat and business process automation.
