More on Why Major Relaunches are a Bad Idea

Jared Spool

August 10th, 2006

Republishing our 2003 article, The Quiet Death of the Major Re-Launch , touched off a surprising amount of discussion, much more than when we originally published it.

Changing Architectures

Some of the comments were about separating out a change in the look and feel of a site from the underlying architecture. People argued that changing the internals, such as implementing a new content management system, search capability, or advertisement management system, can be difficult to do in a piecemeal fashion, making it very tempting to do an entire overhaul of the site.

This could be true. I’ll be the first to admit that I have very little exposure to that side of the business. However, when we watch our large clients, such as Yahoo!, NetFlix, and Amazon do their work, we know that they’ve had architectural changes that didn’t require a major redesign of their entire sites, at least that any user noticed. So, it’s possible to make those changes under-the-covers, without affecting what the user experiences.

I do realize that possible does not equal inexpensive. Costs may make doing this prohibitive. However, design is all about trade-offs. What’s the trade-off of the costs to support multiple architectures in a staged-roll-out versus the costs of the user experience disruption that comes from a sudden major redesign? That’s the question that needs asking.

Reducing Risk

The main impetus behind my article is about reducing risk. Many have heard me talk about the big-box retailer who, in 2003, spent $100,000,000 on a redesign of their site to find, upon their major re-launch, a 20% reduction in sales they never quite recovered from. (Think what they could’ve accomplished if they’d only spent $50,000,000 on the redesign! And, no: I can’t tell you who they are — everyone wants to know {sigh}. I’ve been sworn to secrecy. If I tell you, I have to kill you.)

A major re-launch is risky because:

  • You have a lot of stakeholders – Redesigning the entire site means you have every stakeholder involved. Not just the folks for the major content/application areas, but the folks in charge of the little details, like the investor relations and career folks. That’s a lot of coordination to make everyone happy.
  • You have a lot of personas – A major redesign implies that every persona, including the odd cases (a WSJ reporter coming to get information for a story on the quarterly earnings) need to be considered.
  • You have more code – A major redesign means touching every part of the code. Longer to implement. More bugs to squeak out. More instances of unspoken requirements that get dropped.
  • You are less likely to have a fallback – Often, the changes involved in a major redesign are so extensive they cut off fallback options. If things go very wrong, you’re less likely to have a way go back to the old system.

With a incremental change approach, you:

  • Reduce the number of stakeholders to only those players involved in the particular iteration. Less masters to serve means you’re more likely to meet all their needs.
  • Reduce the number of personas to only those who are important to the iteration. Again, it’s more likely you’ll create a design that meets those personas needs and increases the chance you’ll come up with something they find delightful.
  • Reduce the amount of code, which shortens development time, reduces the bugs needing fixing, and allows teams to quickly identify surprise requirements.
  • Keep an easy fallback option, because, rarely, does an incremental change eliminate the option of going back to the previous version if things go horribly wrong. (Plus, when it does go wrong, fewer users feel the impact and smaller code means fixes are easier to come by.)

While a major relaunch is tempting, when you factor in the time spent dealing with all the things that will likely go wrong, the incremental approach is probably less time. And it’s less embarrassing when Murphy raises his ugly face.

Battling the Cultural Forces

Several people commented on the appeal of dumping everything and starting from scratch. Certainly, I can see where they are coming from. Sometimes, if no real thought was put into where you are today, using that as a base might be undesirable. There might be merit to Monty Python’s “Quickly, Quickly, Run Away!” approach.

But I see a flaw in that logic. Our research consistently shows usability problems are caused by developers making design decisions without all the information they need. If you have a site far from meeting its potential, chances are that’s because a lot of bad decisions were made, which implies a lot of information is missing. Where is all that missing information going to come from? How do you know you have all of it?

Designs evolve in a certain direction because of cultural forces. And cultural forces are hard to shift suddenly. As with anything, incremental approaches to cultural shifts will encounter much less resistance.

Picking an important part of the site and redesigning just that portion will more likely succeed because it will meeting less resistance. And when it does succeed, you’ll have learned a boatload about your users, the needs of your organization, and you’ll get the street cred needed to work on making other improvements.

Add a Comment