July 16th, 2012
If we take the post written by Google UX Researcher Aaron Sedley as Google’s philosophy on why users get upset at design changes, then we can easily understand why users get upset when Google makes changes to their design. From what we know about how users think about the designs they are using, it’s clear Google doesn’t understand why they get the reactions they do.
It’s not that users don’t like change or are averse to it. In fact, people love change. You can see that in the world around you all the time.
One of my favorite examples comes from B.J. Fogg, who says, “If you’re thinking people don’t like to make changes to their behaviors, just watch a teenage girl get her first cell phone.” The changes in her life will be profound and dramatic. And she’ll enjoy every moment of it.
If people love change, why do our users complain when we make changes to our designs? Well, it’s not because of their aversion. It’s because we did it wrong. And that’s the root of Google’s struggle every time they make a change. Google isn’t the only one, either.
Aaron’s post suggests we take the approach we’ve all taken since the ancient times. One that is the software equivalent of ripping off the bandage as quickly as possible. Just make the dramatic changes fast and hope our adoring users don’t hate us for too long.
But what the post doesn’t do is look at the underlying reasons why people hate change. It’s not because of a fear of change itself.
In most cases, people hate change because they don’t like to suddenly become stupid. Think about it. Let’s say you’re a day-in-day-out GMail user. You’ve mastered the menus and commands. You have everything set up exactly like you want it.
Now, suddenly, one day, you arrive at the design and it’s different. All the familiar commands have shifted around. Several are gone. Several are new. Doing those routine, simple acts are no longer routine or simple.
Because of the changes, you suddenly find yourself unable to do the things you once did. While some are smart enough to blame the designers, most will blame themselves. And those people hate feeling stupid, just like everyone else.
Of course, it’s not just feeling stupid. It’s also the change-for-change-sake problem. Chances are, if you’re a regular user of an application like GMail, you probably are happy enough with it. Maybe you’d like to see a new feature or two, but, in general, it works. Especially now that you’ve had time to master it.
When the change happens, often the benefits aren’t clear or obvious. Even when they are, the team hasn’t made it clear why the user has to learn how to do everything over again. Sure, there’s new stuff, but was it worth all the hassle of the learning to do the same things a different way.
The old adage goes: “Good design is invisible.” When someone has mastered our old design, the design itself fades into the background. When the change happens, suddenly the design is back in the foreground, getting in the way of doing the things we wanted to do.
Recently, we were talking with a project manager who got it: “If we do our job well, the users won’t notice anything the day after our launch.” That manager was shooting to make the changes seamless and unnoticeable. The new functionality (and there will be a bunch) will hopefully appear to the users as if it had been there all along.
This, of course, means you have to think about the design ahead of time. Not just what today’s user experience will be, but what the user experience could be in the future. Future-friendly design means anticipating the types of things we’d want to put in our designs so that it feels natural when we put it there.
That’s really hard for some companies. But hard doesn’t mean it’s impossible. Especially if you understand that users don’t hate change. They just hate when the experience of change is poorly designed.Tweet