You are hereBlogs / Jay Small's blog / Redesign/relaunch vs. design evolution
Redesign/relaunch vs. design evolution
I bet if I stopped everyone I saw on the street, nine of 10 of them would have a major Web site redesign sitting somewhere on storyboards, just awaiting final approval from unseen bosses. Web tinkers like me just love doing redesigns, right?
Jared Spool says the big redesign-relaunch cycle often does not work as well as continuous but gradual evolution of site architecture.
"Re-launches are a thing of the past. There was a time when sites launched in cycles, living from one major redesign to the next. Each new redesign would bring a whole new look, a whole new user experience.
"Companies would often hire new outside firms to create and execute these new designs, abandoning the firm that made the previous design. The new firms would try to top the existing design with something dramatically different and attention-grabbing. After all, if you can't notice any change, why did it cost so much?
"However, the best sites have replaced this process of revolution with a new process of subtle evolution. Entire redesigns have quietly faded away with continuous improvements taking their place.
"The big survivors of the dot-com crash -- Amazon, eBay, Dell, Google, Yahoo, and CNN -- have each foregone the big redesign in lieu of continual changes on the site. The changes are so fluid that users hardly notice."
I've done this both ways: big redesign with big launch splash, and years of steady tweaks. I've also made a point of proclaiming "death to the soft launch," so you get a hint of my bias here.
Yet I agree with Spool that evolution makes sense if "it ain't broke"; in other words, if you believe user satisfaction and overall performance of a site to be adequate or better.
It also works best if an executive somewhere up the line strongly prefers things the way they are. Back before the Web, I actually evolved a print newspaper redesign into service over eight months for this very reason.
The publisher's elderly right-hand man loved the look of the paper back in 1964 and didn't care if it was now almost 30 years later. If he noticed a change, he complained.
That paper's typography and overall organization were so dysfunctional it needed a complete redesign. And I know "keeping the boss happy" isn't really a great strategic driver for a design project. But it did provide one important feature -- job security.
So we planned how the design would look at the end of the process, then backed it out into a few almost imperceptible steps a week. We made sure he didn't notice until it was almost done.
Still, I wish we could have done that project with the big relaunch. I know of at least a few big Internet redesign/relaunch projects that worked out well because the old sites had gone for so long without the managed evolution Spool recommends.
Instead, when new features and promotions had been added, they were tacked on, designed independently of the whole such that home pages and major indexes took on that carnival midway look.
With sites that have tens of thousands of articles that defy intuitive categorization (yes, I'm talking about local news sites), the midway look eventually reduces user session depth and repeat usage. In short, people can't find stuff even if they know it should be there, so they give up.
Eventually the problems became so acute that we felt there was promotional and operational value to fixing them in a batch. We knew some people would complain no matter what we did or did not change. And we knew a total overhaul meant a lot of server software work to ensure we did not hose up our search engine rankings in the process of reorganizing all that content.
On balance, it was worth it. So we did it. Then, once the new architecture and visuals were established, concerted evolution could begin.
I say "concerted" because experience on frequently updated content sites tells me it doesn't take long for business tactics to shift and freelance ugliness to ensue. New elements -- again, often designed independently of the whole -- start appearing in the margins of the architecture.
Think of them as double-wides in a historic district.
Thus design evolution brought on by changes in site strategies, as Spool describes, needs to be managed strategically, not case-by-case. Designers mapping out a total overhaul, if one is absolutely necessary, should know the site will grow and change after relaunch. They must anticipate and build in hooks for expansion and renovation.
Afterward, designers should stick to the theme and spirit of the whole design, and use the expansion hooks as intended. It's like a neighborhood covenant in that historic district -- you can make changes to improve aesthetics and function, but do so within the architectural guidelines of the surrounding environment.
And don't leave out the user testing, before and after important changes.
Update (9 p.m. EDT 8/8/06): Spool responds insightfully: "I'm advocating that you break the problem into small bits and tackle each bit separately. Instead of redesigning an entire site, pick an important page and move to the new visuals and architecture for just that page. This is probably something you can do very quickly. Then see how people respond to it." More of the response, and more from me, in comments.
Both blogs
Welcome to my world, my friend. :-)
Hmmm. A choice between a poorly managed incremental change process or a complete redesign. That's a hard one.
Frankly, I don't know which way to go...
Jared, again, thanks for posting your thoughts here.
Ideally, yes, a Web entity would be in a position to isolate infrastructure changes from the user experience. That means:
-- Having enough development and production resources to do the "run parallel" dance. (Yahoo, Amazon, even the BBC, probably so. Most companies I work for/with, apparently not.)
-- Having general management that can be convinced that new infrastructure -- often brought in to address user experience issues as well as internal production issues -- will still generate return on investment if you cascade the UE changes instead of implementing them en masse as you plug in the new gear.
-- Being sure that's true before you try to persuade general management of same. ;-)
Maybe my judgment on this is clouded by experience in corporate environments where one, two or all three of those items are not true.
Believe me, I know "total redesign" is a big risk. I just feel it sometimes outweighs the risk of doing nothing, or of poorly managed incremental change. Companies with a tendency toward that (or living it daily) probably just need to hire UIE for a while, no?
Even in your two cases, you're taking an awfully big gamble that the new system will be an improvement over the old, from a user experience perspective.
Is there a way to minimize risk by keeping those under-the-cover changes isolated from the user experience.
I find it hard to believe that Yahoo!, Amazon, Dell, the NY Times, the BBC, or many of the other sites that remain the same from year-to-year haven't had any major infrastructure changes underneath. (In fact, I know that isn't true.)
Why put the user's experience at risk because you need to change something they never see?
Jared, thanks for stopping by and for the reciprocal thoughtfulness. :-)
I know you're not advocating the bolt-on stuff, and I hope I did not imply you were.
I'm with you 100 percent on breaking big problems into small bits. And I like the approach of rolling in changes incrementally to evaluate effects and reactions, then adapting to them. The vast majority of the time, that works.
I do think there are exceptions.
If I'm starting from an architecture that is so old, tired and just broken that the incremental process seems to add overhead, I might rather take the chance of rolling out changes en masse.
Examples:
-- When a redesign coincides with replacement of a content management system, such that rolling out incrementally requires double-posting or other significant spikes in workload. Been there, done that, got the wrinkles to prove it. (That problem may be unique to high-volume content sites, where data migration from one CMS to another almost always proves expensive and trouble-prone.)
-- When a redesign coincides with significant changes in display advertising inventory models, such that rolling out incrementally means campaigns become overly difficult to manage between "new" and "old" inventory units (again, this may be unique to ad-supported, high-volume content sites).
The good thing about either of those cases, or similar ones, is that they should be rare milestones in the history of a site. That means you could take the concerted evolution path most of the time between those milestones and it would work best.
Hi Jay. Nice, thoughtful response. I'll try to equally as thoughful... :)
There's a difference between making considered incremental changes and just tacking new stuff on to an existing design. I'm not advocating the latter.
Instead, I'm advocating that you break the problem into small bits and tackle each bit separately. Instead of redesigning an entire site, pick an important page and move to the new visuals and architecture for just that page. This is probably something you can do very quickly. Then see how people respond to it.
My guess is your first design will need changes. Because it's just one page, you can make those changes quickly and the schedule impact will be minimal.
Then you take what you've learned from that one page and apply it to changes to a second page. The second page may teach you a few new things about your users and their needs.
You take that and apply it to the third. And the fourth. And so on and so forth.
You're doing the same work as with a major re-launch, just one page at a time. And, by the time you've done the 100th or 1,000th page, you'll know so much more about your users and what they need than you would've if you did all 1,000 pages at once. And the design will be so much better.
This is the lesson we've learned from the big sites.
I think Jay and I are pretty much in agreement on this question.
I know a site (which I won't name to protect the innocent) that Jay also knows well -- it was launched in 1999 with a design much beholden to the CMS. The CMS has been a straight jacket over the years limiting how the design can evolve. It's been managed in that time by three different site managers all with different ideas about what good and bad design is, and plagued by one or two people with the access and interest to take certain elements in their own direction (damn style consistency) -- and other stake holders with their own ideas.
The underlying architecture is a mess.
I don't know what you can do but tear the whole thing down and start over.
That said, I also believe that with a modern CMS and a good understanding of module development, that you can't do a big relaunch and then make incremental changes (in a structured, managed process) as the user case warrants.
One problem that any commercial, large-business-owned Web site is going to have is the problem of multiple chefs cooking the stew over a several years period. That reality needs to be part of the site plan and documentation, too, so that the inevitable damage, hopefully, can be limited.
Also related -- I managed a large site relaunch/redesign, where I also realized we couldn't redesign and relaunch all of the major components simultaneously. Some major sections (i.e. verticals) had to be dealt with at a later date. Certain bosses couldn't (or wouldn't) understand why this approach was necessary. In any business environment, site designers and architects are also going to have to deal with this kind of environment, which makes the compulsion for sweeping changes more tempting, and potentially necessary.
I like Jared's suggested approach, but I think Jay's perspective is closer to dealing with the realities of what news site managers have to deal with.