This Old Site

Anyone who has ever done a home remodeling project knows that you never know what you’re going to find until you start tearing out the walls. This makes it very hard to estimate the actual work involved in a project, since you can’t quantify what you don’t know.

A long-standing website can have many of the same structural challenges as an old house—it’s been managed by different people, with differing levels of skill, over time. Those various owners also had different tastes in décor, so one owner’s beautiful wallpaper is the next owner’s eyesore to be removed or covered up. And change has been made in a reactive rather than proactive way and expedience often wins over doing the right thing. When the roof is leaking, you patch what’s there, putting off the inevitable larger project of replacing the whole thing.  

When we approach a website that has structural, content, and design issues, the expedient thing is to make the easy changes, slap a new coat of paint on, maybe move the furniture around a little, and call it good. But just like our old house, our old website really needs and deserves a thorough renovation. Where do we begin?

What Lurks Inside

Start your redesign project with a content inventory. Just as you don’t know what’s behind those walls until you tear them away, you don’t know what’s on your site unless you do an inventory. Fortunately for us, gathering all that information about a site is something we can do quickly and easily—not to mention more cleanly!—than taking sledgehammer to drywall (or lath and plaster). Run an inventory using the Content Analysis Tool (CAT). In a matter of minutes, you’ll know exactly what you’re dealing with in terms of quantity and type of material on the site. Starting out with that rich set of data--pages, images, media, metadata, word count, analytics information—gives you the bones of what you’ll have to work with in designing the blueprint for your new site.

When you’ve inventoried and started your analysis, layer in your own observations about the content—read it for quality, accuracy, voice, relevance, and all those other characteristics that make good content. (I’ve written elsewhere about conducting content audits, see the Resources page at content-insight.com for a series of articles on the topic.)

Your audit will help you decide what you’re going to keep, what you’re going to remove, and what you need to do with the content to bring it up to your new site standards. Just as in an old house remodel, while you’re in there looking so closely, you’ll want to take the opportunity to clean things up, put in the additional wiring to support current needs and think ahead to expansion—what do you need to build to future-proof your design? Will the structure you’re building support the growth of content and addition of features? It’s cheaper to do the preparatory work now than it will be to go back in later, so take the time to think ahead.

When you’ve done your cleanup and revision, you’re ready to reassemble the site into the new architecture.

The Cost of Poor Communication

Unless you’re a one-person web team, you’re probably working with a group of people who bring other skillsets to the project. Just like on a home project, where you bring in the specialists like plumbers, electricians, framers, drywallers, and painters, you will likely be working with project managers, business analysts, user experience designers, creative directors, and technical folks. Maintaining good, open lines of communication, including documented architectures, content models, and designs is critical to ensuring that the final structure looks and works as it should. If the information architect designs a navigational model that doesn’t map to the actual content or the developer builds templates that don’t support the content model, tearing out and starting over is a much more expensive proposition than making sure up front that everyone understands how the final product is supposed to look and how it will work.

That New Site Smell

Walking into a newly renovated house, admiring the easy flow from room to room, smelling the fresh paint and trying out the new furniture is a great feeling. Launching a beautiful, functional, engaging new website is similar. And just as we need to do regular maintenance on our new home, we need to carefully govern our new site to make sure that it continues to run smoothly and doesn’t accrue ROT— redundant, outdated, and trivial content and features—over time. The ongoing investment to keep things ship-shape will pay off in the long run when the next remodel is just an update rather than a complete teardown.

 

The Long Happy Life of a Content Inventory

The other day, I spent several hours working on a content inventory. No, not a new one. This is an inventory I initially created almost a year ago. Why revisit it now? Because the project I'm consulting on involves replatforming an existing site onto a new content management system. And like many of these projects, it is a sizable and long project, meaning that the content inventory has a similarly long lifecycle. And the inventory progresses through stages, just as the project does.

I run a content inventory at the start of a project like this to get an initial lay of the land—what are we looking at? How much content is on this site? How is it organized now? Where are the problem spots—orphaned pages, duplicate content, confusing navigational model?

As the project progresses and we start to review the content with the business owners and plan for migration, I add more information. Content owner, review status, migration destination, new URL, and so on. But web sites aren't static, particularly over a period of many months. Content has been added, changed, removed. So as we approach the migration of each section, I review the inventory—comparing it to the current site again, making sure I haven't missed anything, since we'll use that same spreadsheet as our map to the new site. The inventory, now generally referred to as an index, will also be used by the production team, developers, QA team, and user acceptance testers to check that everything that was meant to be migrated made it to the new site and that new structure is correct.