One Year Later on Major Re-launches: “We were warned, you have been warned.”

Jared Spool

November 29th, 2007

A little more than a year ago, we republished my article, The Quiet Death of the Major Re-Launch. The article generated an interesting discussion about when a re-launch is warranted.

During the debate, Richard Todd made this observation:

What about the challenges in trying to avoid a major relaunch?

When faced with many new site ideas and a desire to introduce them in a better structured environment, the pressure is on to – while you’re at it – rebuild everything. This pressure is compounded when, regardless of any surface changes, the internal architecutre must be reenginnered due to changes in servers, browsers… the forces without and within. Call it “valid software engineering principles”.

what then? Recreate the old site on a new platform? It would be like putting an old , but not-so-classic, car body on top of a high-end power plant. It works in the funny car races, but that’s why they’re called funny cars.

There are times when a rebuild forces so much change that a relaunch is inevitable.

The other truth is that the transitional approach can be much more expensive. A wholesale change is a one-step event. Transitioning takes planning – each baby-step to pull the audience along with you, can be as expensive. And it often must take place over a long, gradual period of time – this also gives competitors a chance to usurp your ideas before they have finally hatched.

In other words there are forces outside the confines of the user interface and user hand-holding. Not every company can afford the time and extra effort of small steps.

It is a challenge we face right now. I’ll let you know how it turns out – if we go to major re-launch or if we sneak in incremental changes until we get there.

At the time, my opinion was that he should slowly integrate the new platform into the design, supporting both platforms simultaneously for a while.

“Heresy!” the masses clamored. They said I just wasn’t being realistic and understanding the complexities of that. Plus, if you’re going to take the effort to change the platform, they suggested why not do a complete overhaul at the same time? It’ll be much cheaper.

I disagreed. It might be cheaper, but the odds of getting the design right out of the gate are very slim. Better to do it in small pieces, learning as you go.

Well, here it is a year later and Richard has an update for us:

Well, you were right. It is now a year and a bit past the point of no return when we relaunched our website. The site is much better (far from UIE endorsed perhaps but better) in term of navigation, design, content, and all those other reasons why companies decide to re-launch.

But, the truth of it is, while comments from users are favorable, page views have not substantially increased per user nor has time on site. Overall user numbers are a function of other factors such as marketing effort, so we are only looking at the actual user experience.

There was certainly a high curiosity factor in the first month (perhaps the best reason for a “re-launch” – the marketing opportunity it provides). And the functionality under the hood in the new content management system is very robust and flexible and extensible – it had to be done for our authors, and our members, and our sales streams.

But the part of the process where we redesigned the look and feel was the area of fault. It might have been more difficult to reengineer everything while trying to match the old appearance, but in hindsight we would have been better off to do that – to say with the familiar.

Words of advice from an anecdotal experience with the pitfalls of relaunch. We were warned, you have been warned.

Thanks, Richard, for letting us know how it turned out!

4 Responses to “One Year Later on Major Re-launches: “We were warned, you have been warned.”

  1. Daniel Szuc Says:

    Are there examples of web sites that are managing their web re-designs well?

    Perhaps there are web sites that are doing it so well, that its hard to see the changes :) Then again, if you have a solid base to start with, there may be little need for large step changes.

  2. Jason Zipperer Says:

    I would be interested to see any examples of sites that have managed a re-launch well. The team I work with are getting ready to re-launch our site that has been without any major changes for over 5 years. I guess my question would be: “Would a site that has existed largely unchanged for so long be a good target for a re-launch, or would the users rebel from the changes all the more?”

  3. Jared Spool Says:

    I can give you a ton of examples of sites that do a great job of avoiding major re-launches by doing frequent incremental changes: Amazon, eBay, Google, Yahoo!, and Netflix, just to name a few.

    I can’t give you an example of someone who did a major re-launch “well” because I don’t know what that means. Major re-launches are possible, but the risks are very high. Avoiding the major re-launch is a way to dramatically reduce the risk.

    Would a site that has existed largely unchanged for so long be a good target for a re-launch, or would the users rebel from the changes all the more?

    In our experience, we find users don’t mind minor changes. But we find they hate dramatic changes, no matter how frequently the site has been updated in the past.

    Unless you do an amazing job of migrating them from the old design to the new, by giving them very good tools to learn the new site incrementally. However, to do that, you have to actually study how people will migrate. And the more facets of the site that change, the more expensive the research and the development will be. And the more likely you’ll screw it up.

    Again, it’s all about reducing risk.

  4. Daniel Szuc Says:

    Thanks Jared!

    Also be an interesting exercise to help determine what it is you actually want to re-design and change, based on … . What questions we need to ask to better understand the need for the re-design.

    For example, reviewing the site’s existing content and determining what content users need to get to faster may be a much better use of resources, than putting a new design skin on an existing problem.

Add a Comment