A few months ago I posted to designstaff.org about change aversion (http://goo.gl/LqIMx). Jared Spool recently commented on it (http://goo.gl/bWuoN); below is my response:
Hi Jared, thanks for commenting on my post and for moving the public discussion of change aversion forward. Although your headline suggests otherwise, a fair reading of our articles shows that we agree more than disagree about the roots of this phenomenon, and about methods to minimize it.
For starters, we agree on a major cause of change aversion. As you put it, users don’t like to feel stupid. I wrote that "When products change and advanced users suddenly become novices, you should expect anxiety to result." We also both point to sudden, unannounced changes and lack of control as further sources of discomfort. UI changes decrease user control, and necessitate re-learning. Learning takes effort, and therefore UI change invariably comes with cost to users. As Kahneman and Tversky famously note, losses loom larger than gains (http://goo.gl/VKfvk
); this is borne out in change aversion.
We also echo each other’s advice to communicate the nature and value of changes, to let users switch between old and new versions, and to avoid “change-for-change's-sake”. The crux of successful UI change is the simultaneous presentation of clear benefits that outweigh inherent re-learning costs. Using BJ’s example of a teenage girl getting her first cell phone, learning the cell phone UI takes effort, but this effort is far outweighed by the newfound ability to communicate with friends.
We don’t always get change right at Google. In fact, I started thinking about change aversion after seeing several companies, including Google, launch changes which angered many users. In these cases, the costs of change were too high and the benefits were too low, or unclear to users. We do, however, consistently strive to minimize cost and maximize benefit. One strategy to minimize cost -- as you astutely point out -- is incremental change driven by A/B experiments, which are a staple of our user testing strategy. Google constantly evaluates a multitude of potential changes and frequently launches small improvements that enhance user experience. As you also mention, when we do them well, people don’t even realize anything has changed.
Yet some types of change aren’t invisible, and can't be subtly implemented one shade at a time, like your account of how eBay shifted its background color (http://goo.gl/1NQMB
). There are also technical reasons for launching changes non-incrementally, and Google often pairs visual changes with major back-end shifts.
Although most of our attention has focused on UI change, there are additional flavors of design change that deserve mention. Visual design, information architecture, and technological change all come with unique costs and potential benefits. For example, major visual redesigns like Google's cross-product 'Kennedy' redesign (explained here by Google's Search UX Lead Jon Wiley: http://goo.gl/FQ7E8
) do not exact as large a re-learning cost from users, but may not provide as great a benefit as architectural UI changes, such as the 2009 AdWords redesign (http://goo.gl/JoAub
). The mere exposure effect, demonstrated by Zajonc in 1968 (http://goo.gl/VmlqQ
), helps explain change aversion and increased acceptance over time, especially for visual design changes. And with any change, if users' attitudes don’t reach a higher baseline after they learn and adjust, the costs have likely outweighed the benefits.
Major change to familiar products can be risky, but positive change is absolutely necessary, especially in the rapidly evolving online milieu. To quote Heraclitus, “The only constant is change.” Successful designers and researchers embrace change, minimize its costs, and maximize its benefits to users. The willingness to embrace change is critical, because the option to remain static is an illusion. Heraclitus also said that “No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.” Even if our products do not change, judgments about them will, as our users and the technology environment continue to evolve.
Thank you again for your comments. I’m pleased that we’ve identified consistent sources of change aversion and prescribed similar actions to mitigate users’ pain. I hope that our discussion has moved the field forward, has given our audience new ways of thinking about managing change that will happen with or without our efforts, and leads to more positive experiences for all of our users.