Usability pundit, Jared Spool, republished a UIE article from 2003 called The Quiet Death of the Major Re-Launch.  Here’s a quick quoute:

Our findings show that consistency in the design plays second fiddle to completing the task. When users are complaining about the consistency of a site, we’ve found that it is often because they are having trouble completing their tasks. On sites where users easily complete their tasks, the users seem to pay little attention to glaring inconsistencies, often telling us in their ratings that the site was indeed very consistent.

Apparently, the republishing of this article sparked a lot interest and conversation, so Jared has added some additional thoughts today here. Jared outlines why major re-launches are risky (verbatim from the post):

• 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.

He also outlines why an incremental approach is on that companies should consider:

• 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.)

There’s a number of other great nuggets in Jared’s post.  So go check it out!