Who moved my button? 🧀

Everyone is averse to change. Even to the good kinds. How do we take our users with us, when changes in the digital products we build are inevitable?

Using fire to make meat easier to digest was a massive change in the animal kingdom. Surely everyone must not have been convinced.

There could be several reasons why humans are instinctively unwelcoming towards change. Some wild surmises I have are that in the wild, the transformation of a familiar landscape meant losing the ability to know how to use it best in times of danger. The other reason is that an inertia needs to be overcome and effort needs to be made to learn the new landscape. Here’s another take on this from Jared Spool.

Similar emotions are felt in our much tamer lives today, when products that people have been using regularly to get things done, suddenly seem to look, feel and work differently from what they’re used to.

It takes some time before people can fully understand and appreciate the value of the change. As makers of digital products, we need to help our users cross the chasm of change aversion as quickly and smoothly as possible.

Here’s a simplified visual representation of that emotional chasm that exists just beyond the point a new change is introduced:

There is first skepticism, anxiety and then eventually acceptance and adoption.

Some related reading material on change aversion patterns

I was part of a redesign effort for Outlook’s experience on the mobile web browser that shipped recently. I’ve compiled the steps we took as a product team at Microsoft, along with some retrospective learnings.

People use our products to get things done. But they choose us over others for a different reason. How we help them deal with changes has an impact on how they perceive us.

Stage 0: Before the change

Luckily, unlike unpredictable changes in life, we can actually prepare our users for a redesign update.

The following methods can help us move users from a state of ‘neutral disinterest’ to ‘passive curiosity’.

The goal is simply to hint to users that a change is coming and to stir them out of their inertia.

1. Get them to talk: Seek feedback proactively

Lighting up in-product surveys or pushing nudges asking users for feedback, can both feed into our larger pool of knowledge about our users, and also subtly prepare them to expect changes in the future.

2. Give them a taste: A/B test

A/B testing hypotheses and new ideas within the existing version of the product can help us validate concepts at an early stage and also give a glimpse to users of the possible changes to expect in the future.

For example, if for the new design we believe a tabbed approach is better than the existing hub–and–spoke model, we could introduce the tabbed approach to some users within the context of the existing product and gather feedback.

Same but slightly different.

3. Get them to try it

For passively curious users, a beta option is a good way to let them test drive the new experience with the safety net of the old version to fall back to.

This helps us get an idea of potential shortcomings of the new design or challenges our users will face when we finally move them to the new version. This early insight can help us build and tweak a good onboarding and teaching framework (more on this up ahead).

Stage 1: Introduction of the change

Users react very differently when they are finally forced to use the new version of the product, compared to when it’s just an option. This is because they are now expected to do high stakes tasks in a new environment at the risk of making mistakes. This naturally is a stressful mental space to be in.

The following methods can help us pacify user anxiety.

1. Acknowledge the anxiety:

This is mostly a communication exercise to build trust. Whether it’s an email highlighting updates or an in–product welcome screen, the communication should subtly acknowledge that a big change has taken place — but not to worry, we will help them figure it out. It’s also a good idea to remind users how to send feedback or seek help at this point.

2. Demonstrate empathy:

Remember all the data and feedback we gathered earlier in Stage 0? The challenges users faced in the beta experience? This is the perfect moment to use it! By providing well–timed teaching moments, we can help users find what they’re looking for, and help finish tasks easily.

We should make sure our teaching moments are useful and not a source of distraction and irritation.

Some things to keep in mind:

• Keep it light and bite–sized. In the typical first run experience, people tend to either skip or hurriedly swipe through the traditional carousel of updates. Users are here to do a task, so it doesn’t help to put up too many roadblocks in the way, since not all of them are relevant to the task at hand. And if they do carefully read through the list of updates, it is unlikely they will be able to retain all the information and recall it when they actually need to use a feature.

• Anything that looks alien to the UI tends to get quickly dismissed. Which means that onboarding components we design should look at-home with the other components. And whenever possible, important updates should persist on the screen long enough for the user to get back to, in case they’re in the middle of completing a task.

• Block the user only if urgent. Teaching moments that take up the entire screen, or momentarily block the user from interacting with the UI is sometimes essential to give a sense of urgency and importance. On any other occasion however, it is an irritant that gets in the way of completing a task.
• Leverage signals to light up teaching moments at the right time, like session count or predicting that the user intends to do a certain task. This can help us fire up the right teaching moment, and be relevant and useful in the process.

It doesn’t help to unleash all the onboarding campaigns on the user at once.

Stage 2: After the change and beyond

Closely monitoring the success of the onboarding is as important as building the right kind of onboarding. From a bird’s eye view, a low count of negative user feedback is a great sign.

Digging a little deeper helps as well. For example, can we measure if there was an increase in a redesigned feature’s usage after the teaching moment is lit up, as compared to before? Having these insights can help us improve our change onboarding frameworks for the future.

Creating a well–designed, well–intentioned product should always be our priority, but carrying our users through the changes we introduce is just as important for a full product experience.