Users Don’t Hate Change. They Hate Our Design Choices.

A message appeared to users at the top of the screen that was deep in the administration system for Google’s G-Suites apps. It read “The new User management feature has more efficient workflows, time-saving features, insights about account issues and so much more. Try it now.”

The message appeared above a functional list of all users enrolled in that organization’s G-Suite subscription. It seemed everything the administrator needed to do to keep their co-workers happy was available.

Yet, progress is progress and the Google G-Suites designers felt the user management feature, which hadn’t seen much design love since it was first launched, needed an overhaul. They created a new version, which is closer in look and feel to the design system they’ve employed elsewhere. It even had some new functionality for the administrator, though the details weren’t clear from any communication beyond what was in the message.

Clicking on the message did indeed bring up a cleaner, better-looking version of the user management feature. Other than colors, spacing, and font changes, it was hard to see what the difference was.

Giving Users Control Over Design Changes

The G-Suites team made the design changes more embraceable for their users with that simple message at the top of the old design. They didn’t just change it for everyone at the same time. They gave their users an option.

The designers went a step further. For a while, at the top of the newly designed user management feature, there was a sister message informing users they could change it back.

This way, any administrators who felt the new system was disrupting their immediate workflow could click back. They could go back to a design that worked as they previously expected. Those administrators that did go back to the old design could try it again in the future, when it’s more convenient.

Change Can Get In The Way Of Users’ Productivity

These administrators aren’t coming to the G-Suites Administration system to explore new design options. They didn’t wake up that morning saying, “Today will be a fantastic day because I can learn if Google’s designers have come up with a new user management feature.”

They’re coming to add users or make access changes. They may have some manager screaming at them for not adding a new employee quickly enough. Someone may have just been fired (or about to be) and they need to remove them from the system before they can steal company secrets.

The administrators are solving problems. They don’t want to spend a lot of time solving these problems. They want to make the changes with the user management feature and move onto their next task.

Designing for Embraceable Change

There’s a myth out there: Users Hate Design Changes. This isn’t true. Users don’t hate design changes, they hate the choices designers make when rolling out a change. That’s a nuanced, important difference.

Any G-Suite administrators reacting negatively to the new user management feature didn’t hate it because they hate every change to their tools. What they negatively reacted to was how the Google designers made the change and what was changed. Had the designers made different design choices, those administrators would’ve been fine.

Often, designers roll out a new design without any warning. Users now face a design that looks and behaves differently from how it looked and behaved just a day before.

A rollout like that would likely make the users angry. And if you asked them why, they might even say they hate change.

Yet, we know these same users don’t hate change, because they have changes in their life all the time. They buy new computers and phones. They switch to new software. They add plugins and extensions. The systems and designs these users engage with change all the time.

We’ve found users only hate design changes some of the time. We as designers can design for that. We call it designing for embraceable change.

The Research Behind Embraceable Change

For years, we studied teams rolling out new designs, to see if we could mitigate negative reactions to new releases and design changes. We studied hundreds of product and service rollouts. We watched and learned from the reactions of thousands of users.

When we dug into what those users’ reactions were, patterns emerged. The users told us the changes inconvenienced them. They had no idea the change was coming and suddenly it was in their face. Users were upset because they were surprised.

They also told us the old version worked fine. Even when it took a while to get comfortable, they learned it. Many users mastered difficult-to-use designs.

Everything was different when the new version arrived. What they’d mastered before didn’t help them now. The company said it was an improved design, but they couldn’t see the improvements. Why should these users learn something new that doesn’t help them? Users were upset because they couldn’t see the value.

We also saw many instances where users didn’t react negatively to changes. Often, they didn’t react at all. We saw new designs that didn’t affect the users’ behaviors and they didn’t pay attention to it.

In these cases, the changes were often not noticeable. Sometimes the changes were small and isolated. Yet, we also saw users seemingly not notice several updates with extensive changes. (In more than one instance, an entire application’s infrastructure had been rewritten without a single user noticing.)

In cases when the design changes were noticeable, the designers gave the users control to switch when they wanted. The designers showed why the change was valuable to the users. And the designers made the transition easy by taking the knowledge and experience their users already had with the product into account.

The Principles of Embraceable Change

Our research led us to codify four principles that separated those instances when users reacted negatively to change from whose times when the users embraced the change:

Embraceable Change Principle #1:
Reduce the change to the smallest units possible.

If the user can’t see the design changes, it’ll be hard for them to react negatively to those changes. Often designers pack a lot of change in all at once. Yet, in this day of continuous deployment, designers can break up each change and phase them in slowly, removing the jarring impact of sudden, obvious changes.

Google’s designers could have slowly changed the user management feature over several weeks or months. Each individual change would be insignificant and not draw the user’s attention. Colors might change one week, fonts another. Most users wouldn’t notice.

Embraceable Change Principle #2:
Give users control over when change affects them.

The designers of G-Suites’ user management feature gave their users the choice of using the new design or staying with the old one. They gave them the choice of switching back.

When users have control over when the change happens, they can do it at a time that’s convenient. There’s usually no reason why changes must inconvenience the users.

Embraceable Change Principle #3:
Show users how the change benefits them.

In our research, users often complained that they couldn’t see any benefit from the changes forced upon them. In many cases, there were benefits for those users, but those benefits weren’t explained.

For example, the designers thought they were improving the design by making hidden features more visible or by grouping basic functionality in a more logical way. Yet, the users didn’t see these benefits. To the users, it was change for change sake.

Sometimes it was. Often changes were introduced because it was a new release and new releases demand things change. (No wonder users dread new releases.)

When designers show the new design’s value, it elicits a user reaction of “Nice.” Users get excited to use a new design when the benefit is clear. “It’s like the designers were reading my mind,” one user told us.

Embraceable Change Principle #4:
Respect the users’ existing investment in your design.

Poor design choices might make the existing version complex and hard to use. Yet, users still figure it out and use it.

Users made an investment to get benefit from our existing design. They put in the time and energy to learn what we’ve built for them, no matter how awful a job we’ve done.

It makes sense we want to improve it. However, when we force users to throw away their investment, they are rightly upset.

Instead, we can design for what the users already know. We could provide multiple ways of accomplishing the same result. Or we could provide a gentle retraining capability, keeping the old way working while we slowly transition the users to the new, better way of attaining the same results. Either way, we respect what the user already knows.

The Users’ Experience Is The Heart Of Quality

There’s an old saying: Once you eliminate quality as a requirement, everything else becomes easier and cheaper. To our existing users, stability in the design is a sign of quality. When the things they’ve learned and mastered stop working, they see us diminishing the product’s quality.

Yet, 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. We’re giving ourselves an out because we feel it’s something out of our control.

Declaring it out of our control is the easier, cheaper path. In some cases, it may even be the right thing to do.

However, we can control it. It’s our choice. When we choose that easier, cheaper path, we’re sacrificing our users’ experience.

If we’re ok with our choice, then we should make it and stand by it. We shouldn’t blame users because we believe they’ll hate us no matter what. We must acknowledge the users hate our choices, not change itself.

Building Towards Invisibility

Good design is invisible. It’s like the air conditioning in the room. If you’re aware of the air conditioning, it’s probably because there’s something wrong. It’s too cold, too warm, too noisy, or it’s leaking. The best air conditioner is one you don’t know about.

The same is true of change. The best way to design for embraceable change is to make it invisible to the user.

One product manager we recently worked with was dealing with a massive architecture redesign. Yet, his goal was to make the change invisible to the user. “If they notice the change, we’ve done it wrong,” he told us.

As I was writing this article, one of my favorite to-do list apps, Culture Code’s Things, released its version 3.5 with “a ‘Spit and Polish’ release that combines 29 great little features and improvements into one big update.” Not only are Culture Code’s designers intentionally introducing change for their users, they’re proud of the change.

We say users hate change, yet we insist on big releases like this. When we give our projects names like New Release, Product Upgrade, or Digital Transformation, we set the expectation that something will change. If the change isn’t visible to our co-workers, then we fail to meet that expectation. After all, what was upgraded or transformed? It didn’t happen if you can’t see it.

Fortunately, large releases, upgrades, and transformations aren’t the only alternative. Continuous deployment methods roll out small changes constantly. They allow us to break up the changes into very small bits—so small the users may never notice them.

Designing in a continuous deployment environment is very different from designing for milestone-based release dates, where the changes are bunched up and need to be compelling to sell the idea of forward progress. We need to learn how to show our work’s value in continuous deployment environments.

Users Don’t Hate Change. They Hate Our Design Choices.

We can take responsibility for creating the poor experience that many users face when we change our design out from under them. That doesn’t mean that we shouldn’t make changes. It means we should be thoughtful about how we migrate users to the new design.

Designing for Embraceable Change gives us principles to work with. With these principles, we can look at the experience of change for our existing users, as we enhance the capabilities of our designs. We can minimize—and possibly eliminate—the friction that comes from changing our designs for our users. That will keep them happiest, while letting us integrate what we’ve learned.