Introducing Change

Humans on the whole, are uncomfortable with change and find the process unnerving. It is hard wired in to our being to keep us safe. What is familiar can be controlled, managed or manipulated, what we do not understand could yield danger.

People create cyclical behaviours, set patterns that make their brain feel at ease and in control of their life. The weekly meal plan with the same 5 weekday meals re-occurring is a prime example of this. If you were unable to purchase the regular cut of beef for steak night, instead of abandoning the idea of steak entirely your brain will seek to change the meal as little as possible and look for another cut of meat that is as close to the original desire as possible. If you were unable to obtain beef at all breaking the usual cycle, stress begins and the brain spirals, latching on to anything else that may be familiar. A common trick the brain employs is to swap the days the meals occur and return for steak tomorrow instead, a subtle change to the week but overall not too jarring. Maintaining what is expected with the smallest of changes.

As the brain moves away from the familiar it gets more and more devious in trying to return to what is familiar. If the new change is too far removed from the usual pattern of behaviours, it will find a way back to its default pattern. It is only a matter of time.

When introducing major change to a brain it will go through the following pattern:

1. Rejection - This is not familiar, I am unsure or do not like this at all.
2. Ambivalence - I don’t care about this, or stay away from it.
3. Familiarity - This is how it is, I expect it to be this way.
4. Advocacy - This is how its always been. I feel comfortable.

It can take anywhere from 18 days to 254 days^[1] to reach step 3 and accept the change in to our lives.

Websites and Software are not exempt from this type of behaviour. Introducing change in to our interfaces can cause large amounts of stress to our users and possibly drive them away all together. The fabled ‘hot new look’ or ‘complete redesign’ are often rejected outright due to the way most people’s brains work.

It is not advisable to redesign an entire system or website in one release. Iterate small areas slowly over time and minimise the risk users will reject the change promoting a feeling of excitement and attention to detail as smaller improvements are introduced. If very small changes are made often, over time the brain will learn that visiting your website or using your software will mean a change has already occurred, in time they may even expect it to be a common trait. Meter out larger changes to a system or changes in workflows and primary actions, rather than introducing them all at once.

For high volume websites and systems, create a planned roll-out of new improvements to the system, stage smaller releases in between farther reaching changes. Where large change is going to occur, produce blog posts and news articles prior to the event informing users that the change is coming. Users may get upset at this point, be prepared to field questions as to why the change is occurring. Reasons for change help the rational part of the brain latch on to something, increasing familiarity. Be sympathetic, users needs should not be undone for aesthetic reasons or at the expense of removing functionality.

When considering change, pave the cow paths. Users shouldn’t have to learn 2 ways to do the same thing and they are more likely to embrace a change if it is already a mechanism they are familiar with.

Once a change has been implemented, it should be tested against the existing solution and the data measured (with agreed business criteria) to ensure it is performing as intended.