How to control Web site sprawl: The big picture

zombies_run

In a previous post, I outlined a common problem many companies face after a few years in business: Web site sprawl. What starts out as a single company Web site can easily evolve into an unwieldy collection of sites scattered all over the place. Like a Zombie horde attacking your city, this is usually not a good thing.

It may seem hopeless, but there’s a way to bring order to this chaos. The approach is pretty simple:

  • Consolidate sites where it makes sense
  • Kill sites that don’t do any good
  • Leave everything else alone

A simple analogy: City libraries

Imagine a company as a city with 10 libraries. Budgets have become tight, and management has become challenging, so the city has decided to consolidate six of these libraries into one, close two small branches and give away all the books, and leave the other two specialty branches alone.

For the six libraries the city is going to consolidate, the process is straightforward. Those libraries will likely have a number of books in common, but many that are different. After determining which books to keep from each library, the city needs to identify where to put them all. Ideally, one of those libraries is big enough to house the desired collection (and hopefully easy to find). If that’s the case, then they move books from the libraries that will be closing into the target branch (possibly after a bit of remodeling). If they don’t have a library big enough to house all of their books, then they’ve got to hire an architect to design and build a new central library.

With the space problem solved, they can move on to (re)organization. They want to make sure it’s easy for people to find things in their new (or remodeled) central library, so they organize things in a smart and intuitive way. After the move and organization are done, they can close the four branches that aren’t needed anymore, and then unveil their grand new collection!

Connecting the dots

It’s not a perfect analogy, but it’s pretty close. The books and other media in a library are just the content (e.g., text, images, videos, music, downloadable stuff) in sites. As in the case with libraries scattered all over town, the content in a company’s sites will likely "live" in different places (e.g., distributed databases, content management systems, static Web pages). Similarly, the A/V equipment or other tools one might use in a library (e.g., projectors, terminals to search for books) would be the applications a company’s different sites contain (e.g., search, user registration, profile management, e-commerce checkout).

The actual process of designing a new library (or remodeling an existing one) is analogous to the experience design process for Web sites. Good experience design organizes content in an intuitive way, just like a library should. And getting that design right usually means bringing in a specialist. In the case of designing or remodeling a library, this would involve librarians (to assess how the space must meet the needs of patrons) and architects (to design a space that meets those needs). In the case of Web sites, design is done by a collection of experience designers who know how to create great online experiences that meet the needs of site visitors. Finally, getting it all done requires someone to actually construct what’s been designed. In the case of the library, this would be a general contractor; for a Web site, a team of developers (e.g., front-end developers, database or system architects, engineers).

Next up: The nitty gritty

With this analogy in mind, we can now turn to what it takes to go through this process for a real company Web ecosystem. In my next post, I’ll offer a step-by-step process for how to control the Zombie Web site horde. Stay tuned!