Who moved my (virtual) cheese?

I prefer to go to the same supermarket. Even though it’s not the best supermarket, I know it, and I’ve learned its layout.

When my wife proposes to go to a different one, some aversion pops up in my head. I know I will have to re-learn the layout of the supermarket. I know I’ll have a certain amount of frustration finding certain items.

I once had a tantrum of which I'm not really proud of, where I cursed the supermarket (and actually the entirety of Mexico) for not finding bread yeast. Only to look like a complete idiot when I found hundreds of packets of yeast later, on a different floor.

As humans, we are creatures of habit. A topic that has popped up in recent software conversations is the topic of “who moved my cheese?”.

Just like with physical spaces, we create a mental model for virtual spaces, and when that model is flipped on its head, we can be disoriented.

When Facebook redesigned its user interface some years ago, many people had trouble finding the buttons they were used to. For example, users struggled to find actions that they were used to do, like remove a member from a group or to find their private messages.

When you have a habit of using something, and the location of a user interface element changes, you have to change your habit.

When Figma redesigned its software, as a user knowing the location of each control, I got frustrated with some parts of the redesign. After 9 months, I am still slightly frustrated by the change and I don’t think the new UI is better.

A question I ask myself though, is whether the UI is better for a new user who doesn’t have the “curse of knowledge”. A lot of habits are learned. Once we learn them, they suddenly are “obvious”; and we tend to forget the time when we were struggling.

A curious phenomenon manifests itself in software discussions, where the person in charge of designing the software — or is often deciding about the software redesign — is usually the person who knew the most about the software itself.

I once encountered a client, more than 10 years ago, that was involved in the design process of his complex software from the ground up, and basically rejected any idea we had.

He was infamous in his company for being stubborn and proud about the way he had built up the software. We were the consulting company hired to bring change, but it was immediately obvious we could not affect any change, because there was no willingness to do anything about the software. Talking about this situation a few years later, many people affirmed that no matter what you proposed, that person would always “know it better”.

But, change is sometimes needed. A usability mistake made 10 years ago can still haunt a software company today.

When working on a software redesign, I have a few guidelines.

The first one is to truly understand how the software works today. Which features are commonly used? What are the core workflows? Which parts are ignored by users? By understanding the current users, you can make better decisions.

A second guideline is to focus on usability fixes within the current information architecture. That means it’s not necessary to move around the way that the different screens of the software are organized; but rather that it makes sense to look into the usability details of the inner parts of each screen. Which process can be done in a fewer clicks? Which control might need a label? Which UI control could use a usability fix?

It's tempting to change the navigational logic of a piece of software entirely. But I find this is often the part that leads to the “who moved my cheese”-effect that this post is named after.

When changing navigational logic radically, my guideline would be to offer the new navigation logic as an opt-in feature to not affect daily work. Especially when software is part of a daily operation in a B2B context, don't just ship the redesign in one go. Put the redesign behind a feature flag and make it an opt-in feature. Push the new UI to an ever-growing audience until finally, you pull the plug and make the old version unavailable. Beware of maintaining two designs of the same software for a long time. This is a software engineering pain in the long run.

Finally, when doing a redesign of software with a lot of users, it pays off to provide accurate help materials how to use the new user interface. This can take the form of videos or a help article. In general, you would be surprised that adjusting to a new interface doesn’t come as natural as it does to people that live and breathe IT. Your users will accept change, but give them some time to do it, as well as the necessary resources to get used to a new user interface.