The Web Diet: how to simplify your website

This was originally posted on the WelchmanPierpoint blog in 2009. I have left terminology as it was written at the time (such as "Web site"). Many referenced pages have disappeared or URLs changed since it was originally published. I have removed or changed some links, and added some comments (comments are always in square brackets []). I also included some final thoughts at the end of the article.

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" [this was an article on the WelchmanPierpoint blog], 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 [see my Size and Complexity Calculator], 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 [although the link to the calculator has changed, it still looks like the same calculator widget from a long time ago]), 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. [Also see my Microsite Checklist, since one of the quickest ways to add fluff is microsites.]

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. [Note: one of the reasons I created Content Chimera was to be able to do large-scale inventorying and content analysis, which can include things like trends over time.]

Remember:

1. Smaller sites are easier to manage and probably easier to use

2. There are many areas where a site can slim down

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

[Now that it's been over fifteen years since this was first published, I wanted to make some observations: 1. Many (most?) digital presences still need to simplify, and the basic approach above can still be useful. 2. LLMs will probably increase the impulse to create more content, and we should probably try to tame that impulse (or at least do it in a controlled manner). 3. I would say that one thing that's not listed above is the need to focus on the audience needs as a way of reducing content -- I've seen that used effectively as a way of removing a lot of content. 4. One element that I frequently use in my practice is carefully thinking through the structures that allow people to naturally "do the right thing", such as carefully thinking through template structures vs. just running toward the current "page building" approach in all cases. 5. I think one of the problems with LLMs is we are all essentially racing to the average (since that's what LLMs have been trained on], and so I think the importance of clearly writing about what's unique to an org is essential -- so this factor should be a key part of deciding how to slim down. 6. When working on removing content for a complex digital presence, I have never just stared at a spreadsheet -- use rules instead. 7. Just as when this was written, sometimes folks may misinterpret this as me saying that all sites should be small -- this isn't the case. I mostly work with large and complex digital presences, and the point is just to simplify and reduce as much as possible. Thanks to Kristina Halvorson, Jeff MacIntyre, and Lisa Welchman for the original amplification of this article, and to Hilary Marsh for encouraging me to resuscitate it.]