Published: Mar 20, 2013
The big box retailer had spent $100,000,000 on the redesign effort. That’s right. One hundred million dollars on redesigning their e-commerce site.
The day they flipped the switch and launched the new site, sales dropped by 20%. (This was a site that was doing almost $1 billion in revenues per year, so 20% is a lot of money to lose.)
It took the company three and a half years to get sales back to where they were the day before the launch. That’s what $100,000,000 buys you. Imagine what they could’ve gotten had they only spent $50,000,000.
I’d like to say this was an uncommon outcome, but it wasn’t. Sure, it’s not everyday that companies spend that much money. However, they do spend a lot of money on their redesign efforts, only to see similar results.
It may seem counter intuitive, but Flip-the-Switch redesigns turn out to be the most ineffective way to get major changes into a design. They are overburdened by corporate politics, the need for every one to get their piece of the pie, and huge expectations of amazing improvements the moment the new design is launched. The expectations are rarely realized and everybody is left wondering what just happened.
Part of the problem comes with the attitude of having a single moment when you’ll launch the new thing. Suddenly that launch moment becomes everyone’s focus. Nobody wants to have their new feature or capability left out.
That’s what happened to the big box retailer. They decided the relaunch would be perfect for an entire new e-commerce platform. It would let them integrate with their retail stores. They could redo the loyalty rewards system. They could faceted search and integrated checkout systems. Everything was possible — let’s get it into this redesign.
Suddenly, the scope of the project was immense. And when it failed, it was too late to turn back. It couldn’t be undone. That’s why it took more than three years to return to the pre-redesign levels.
It’s your most loyal customers who will hate your flip-the-switch redesign the most. Designers are quick to declare, “Users hate change.” But that’s not it at all.
Your loyal users have invested a lot over the years mastering your current design, to the point where they are fast and efficient with everything they need to do. When you change it, even with something you want to label “new and improved,” all of that investment is flushed down the drain.
We can explain this with our model of how people learn to use designs — what we call The Magic Escalator of Acquired Knowledge. On the magic escalator, we’re interested in two points: Current knowledge, which is what our users know when they come to our design, and target knowledge, which is what our users need to know to accomplish their objective. (More background: Riding the Magic Escalator of Acquired Knowledge)
Loyal users have high current knowledge that’s very close to the target knowledge they need. They already know what they need to know before they start using the design to accomplish what they want.
However, when we launch a major redesign, we blast a huge hole in that current knowledge. Suddenly, those loyal users are no smarter than new users. They have to struggle like everyone else.
This is especially painful if the redesign showed up without warning. The user arrived thinking what they wanted to do would be easy and straightforward. They surprisingly discover it will be complicated and they didn’t allocate the time to do it.
Losing that knowledge and getting slammed into more work than they expect is what users hate. It’s not change. Instead, it’s feeling stupid when they previously felt smart.
To get past this, we need redesign strategies that are more effective than the traditional flip-the-switch approach. Here’s three that are extraordinarily radical, which we can use independently or in combination:
“If we do our job right, on launch day, not one user will notice.” That’s what the development manager told me about his redesign. It’s a strange thing to say about two solid years of hard development, but he meant it.
The team was about to release a complete rewrite of the underlying platform. Their old CMS (if you could even call it that) and delivery platform was more than ten years old and buckling under the demands of the organization. The only way out was to rebuild the entire thing.
They had been tempted to, while they were at it, put an entirely new user interface in play too. However, they managed to resist that idea, because, frankly, the new technology stack was challenging enough.
Over the last few months, they’d been slowly fading in pieces, testing small chunks. Because the UI remained the same, they could substitute the new technology in for low- risk areas and see how it held up to the demands. They’d then make small tweaks, and in a couple of cases, felt the need to role back to the old technology before they tried again.
Now, the development manager felt ready to pull the trigger on the final pieces of the site. From the users’ perspectives, they might only notice the speed increases and less weird error messages. Otherwise, it should feel exactly the same.
At least, it’ll feel exactly the same for now. Once they are running under the new platform, they’ll have all sorts of room to make changes to the UI. However, it’s likely the employ one of the other effective redesign strategies to ensure success of that phase.
We used to joke about making a t-shirt with the saying,
The great thing about users is eventually they die. It sounds cold-hearted, but there’s definitely a truth to it.
Those loyal users are wedded to our old design, but the new users, well, they haven’t had the chance to learn it yet. (It might be that the old design has become so complex that only people who’ve used it from the beginning can make it work. That’s why we’re considering the redesign to begin with.)
What if we left the old design in place and made a different platform for our new users? This radical approach was first used by Microsoft back in 1988, when they introduced Excel 3.0. They built two separate interfaces to the spreadsheet. One was for users who had grown up on Lotus 1-2-3, the market leader at the time. The other was for users who were brand new to spreadsheets and never learned Lotus 1-2-3.
Microsoft’s strategy was a hit with both user groups. The existing group of Lotus users found the program to be familiar, while the new users weren’t burdened by the obscure keystroke commands of the competitor’s software. Over time, as Lotus lost its market dominance, Microsoft could phase out the Lotus 1-2-3 emulation software.
Last year, 37signals did the same thing with their new Basecamp release. A rewrite from the ground up, it has an entirely new interface. However, the smart folks at 37signals didn’t force their existing users to switch. They just put the new version out for new customers.
Existing Basecamp customers could still access the familiar interface of the old design, but had the option of starting new projects, whenever they felt ready, in the new design. They could control which they used. It’s likely there are still many folks who haven’t switched, even though new users are getting the new system. It’s painful to support two separate systems this way, but the savings comes in customer loyalty and the reduced costs of dealing with disgruntled loyal customers who were more comfortable with the original design.
I regularly ask people when they think the last time Amazon.com redesigned their site.
They’ve never redesigned. is often the response I get. It’s only sort of correct.
Amazon.com has redesigned constantly since their launch. Their philosophy is to make a ton of small changes constantly. So constant and so small that most people hardly notice the change.
The beauty of making small changes means that you never have high risk. A menu item here, a new form field there. Slowly the interface morphs, and if you make a mistake, well, you change it back.
This type of redesign takes patience. It also takes humility, especially from those organizations who think people want to hear that they’ve made it better. Unfortunately, to most people, those proclamations sound like the web equivalent of “Our menus have changed so please listen carefully.”
To pull this off, the team needs a solid vision of where the design should eventually go. Then, one small change at a time, they start in. Make the change and watch what happens, proceeding slowly to the next. The team will know it’s succeeded when they hear a user insist that a new addition has been in the design all along.
We all grumble when the designs we use every day decide to change suddenly. We need to respect our users and understand they don’t like it when we do the same thing to them.
The radical approaches aren’t the easiest to do. Nor are they the least costly, on the surface. However, the risk of failure and rejection is substantially minimized, making them far more appealing to those who want to look to the long term. After all, spending millions of dollars to achieve huge losses isn’t a great deal either.
Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems.
What strategy have you put in place when planning a redesign? Share your success stories in our blog.
Read related articles: