Small Web sites are easier to manage than large ones. Since this is obvious, why don't more sites choose to be smaller?
Of course some sites need to be larger than others. A baby blog with the purpose of sharing news with family will certainly be smaller than a global suite of sites for a major corporation. Even for a site that needs to be relatively large, couldn't the organization choose to make the site smaller? Just yesterday Harvard Business blogged Simplicity: The Next Big Thing, stating that the next big trend for corporations is to simplify, in part by streamlining business processes. As part of your strategy for managing the Web in a recession, perhaps now is a good time to have your Web site go on a diet.
What does "Large" Mean Anyway?
Lisa Welchman and I have been working on the definition of Large Sites, but for the purposes of simplifying your Web site, here are some ways your site will feel Large:
- Sheer number of pages, content items, or templates (definitions of each of these may vary)
- Number/depth of systems/applications being integrated
- How dynamic and/or automated the site is
- Number of brands/sub-sites
- Number of ways users can get to your content (content re-use across Web pages/brands/sub-sites, APIs, RSS, internal database calls, etc)
- Complexity of interrelationships between content (for example, how complex multilingual relationships are maintained)
- Inconsistencies between sites
So a baby blog may have a small number of blog posts, only one or two templates, no systems being integrated, with no sub-sites, and only available via one page per blog entry. IBM's corporate suite of sites has all of the above, to the max.
The point of this isn't to come up with a formula to calculate the size of a site (like a Web equivalent of BMI), but just to point out that you probably have size factors that can be reduced. The easiest to cut is probably the first one: the amount of content in your site. This also includes what many large bureaucracies end up creating, which is duplication of content and even sites (for example, two different groups looking at the same topic from slightly different angles). Another key way that sites get larger is by not being consistent — adding a hundred countries sites that are all the same may make the site feel larger than adding three applications that are entirely different. But each of the factors above could be reduced as well.
What are The Impacts of a Large Site?
Before diving into more about how to simplify your site, let's review why a larger site leads to problems:
- Reduced Usability. In general, adding functionality should not be taken lightly since it can reduce the site's usability. I thought Jared Spool's tweet yesterday was compelling: "I could see an argument for reducing functions to improve UX here: Hand-managed-pages -> CMS -> Blog -> Tumblr -> Twitter". 37signals ("Our products do less than the competition — intentionally.") and others have made many successful and compelling arguments for reduced functionality to improve usability. One of the problems with a Large Web presence, if it's not Product Managed, is that functions keep arising from different groups and it winds up being a hodgepodge of confusing functionality (each on its own may even be good/interesting, but in the aggregate it's confusing). In addition, without better editing of content, even a single page can be less easy to use (having a strong Design & Editorial team can help here). Also see Paul Boag's #10 "You Have Too Much Content" in his excellent Smashing Magazine article 10 Harsh Truths About Corporate Websites.
- Inability to Manage. This one is obvious, but easy to overlook. The more stuff (content, functions, sites, etc, as listed above) you add to your site, the harder it's going to be to manage it. In addition to there being more to deal with, often the nature of managing the amount of content changes. For instance, if you have hundreds of thousands of pages, then necessarily you need more people. This then means you need more training, documentation, etc.
- Diluted Brand. Once you add more and more stuff to your site, it becomes much more difficult to control your brand. Of course, now your brand image is being determined in a very broad way that is largely out of control, but you might as well be in control of what you theoretically are in control of.
How to Slim Down Your Web Site
This is a bit like any other diet. There are many ways to lose weight fast, the easiest being just not moving over your ROT (Redundant, Outdated, and Trivial) information during a content migration. When that new application is proposed that gets everyone excited, however, it's tough to say not to add it (or to step back and think about how to roll it out as a beta and pull it back if not successful). So how do you keep the weight off? Specifically, how do you slim down a site that needs to be relatively large (the rules below aren't entirely relevant for small sites, since a smaller team can just make it happen directly)? Well, like a diet, the details aren't that exciting, but here's an approach:
Step 1: State slimming down as a priority
At the very top of your institution, this should be part of a Guiding Principle for the Web. At this level, it won't be very specific but key terms like "efficiently managed Web site" or "easy to find information" may help set things up. Also, senior executives need to delegate the authority to someone to actually make this happen. At web4dev, David Pullinger reported that the UK government has been closing more than one Web site per day since 2006. Without Gordon Brown specifically pushing for this, this probably would not be possible.
Step 2: Define policy and standards to make it easier for people on a day-to-day basis to not introduce unnecessary fluff
A policy could be that only meaningful and unique sub-sites be created (possibly backed up by a policy to review any request for a new site), and that sub-sites should also follow the standards of the organization. The standards then should be defined so that even when new sites or content are added, they are added in a consistent manner which will have a slimming effect on the site.
Step 3: Set up the required teams
The exact structure of your teams depends on your organization, but one thing is for sure: you need Web Program Management, Web Product Management, Design & Editorial, and Information Organization & Access. Having centralized Web Program Management (including budget) will help ensure that spurious sites are not created. One of the most important roles is Web Product Management, where someone is managing your entire Web presence as a product. Similar to how products can be much more elegant with less features, the product manager drives the direction of the site (including saying no to some new requests). Design & Editorial and Information Organization & Access teams need to help drive the 'less is more' mantra as well.
Step 4: Measure
What's the scale for measuring site's size? This should be defined up front, tracked, and reported on. For example, if you say that you're cutting back on the number of applications on your site, then make sure there's a way to track and report that. Automated systems may help on some of the measures, such as the total number of content items in your site.
Remember:
- Smaller sites are easier to manage and probably easier to use
- There are many areas where a site can slim down
- By taking the steps of prioritizing, setting policies and standards, defining appropriate teams including Web Product Management, and Measuring, you can make your site smaller.
Note that here I don't delve into the broader issue of your total Web presence, which includes many of the ways you interact with the world outside your site (partner sites, social networking sites, etc).
This was originally posted on the WelchmanPierpoint blog.
