CMS Fridays: When “Too Much Content” Is Really Too Much, And How To Plan For It

I love lists. I especially love “Top 10″ lists because anything with more items than that are too hard for me to remember. I think anyone who has worked on a website project can relate to some part of this: 10 Harsh Truths About Corporate Websites from Smashing Magazine.

Here’s the list, but check the article itself for detailed descriptions of these:

1. You Need A Separate Web Division
2. Managing Your Website Is A Full-Time Job
3. Periodic Redesign Is Not Enough
4. Your Website Cannot Appeal To Everyone
5. You Are Wasting Money On Social Networking
6. Your Website Is Not All About You
7. You're Not Getting Value From Your Web Team
8. Design By Committee Brings Death
9. A CMS Is Not A Silver Bullet
10. You Have Too Much Content

I’ve worked with several clients who have implemented content management systems without realizing the implications of the technology — my role included assisting them with “content scrubbing” before their public go live date.

Consequently, You Have Too Much Content is always on my mind.

Part of the problem with content maintenance on large corporate websites is that there is too much content in the first place. Just because there’s no limit to the amount of text you can put on the web means you should put everything, but most companies do. Most of these websites have "evolved" over years, with more and more content having been added.

Some projects I have worked with have over 10 years of content that’s grown like the Winchester Mystery House; with larger website implementations, few review the content and asked what could be taken away, because content migration and governance is never planned for at any stage of the evolution.

Many website managers fill their website with copy that nobody will read; this happens because of:

• A fear of missing something: by putting everything online, they believe users will be able to find whatever they want. Unfortunately, with so much information available, it is hard to find anything.
• A fear users will not understand: whether from a lack of confidence in their website or in their audience, they feel the need to provide endless instruction to users. Unfortunately, users never read this copy.
• A desperate desire to convince: they are desperate to sell their product or communicate their message, and so they bloat the text with sales copy that actually conveys little valuable information.

Steve Krug, in his book Don't Make Me Think, encourages website managers to "Get rid of half the words on each page, then get rid of half of what's left." This will reduce the noise level on each page and make the useful content more prominent.

In a few cases, the clients have done the right thing: they have taken the opportunity to”clean” their content along with presenting a new look and feel of a new public website. More often, corporate website projects are under such tight deadlines to complete a project from a technical point of view, the very content that needs to be managed is not considered until the last moment.

Many organizations, particularly ones where there might be many content owners, struggle with knowing how much is too much and when it’s appropriate for something to be removed or archived.   Furthermore, some organizations only address these issues when they are doing large revamps  or overhauls of their sites and “content freshness” is rarely a high priority item.

There are no hard and fast rules about managing content, but I think what a lot of organizations fail to do is even consider these issues, nor do they lay down any rough guidelines for content owners to work within.

The takeaways:

• The reality is most corporate websites could get away with 20 pages, tops. Just because the page is up there doesn’t mean anyone’s going to visit it.
• When putting up content in the first place, think about how that content will grow in the next five years. Then plan for it.
• When migrating content to a new site, build in time to pare the content — don’t think it’s a straight migration, because the new site will have a completely different information architecture.
• At the very least, establish content standards before the project begins. Remember, it’s a content management system, not a technical management system.

Comments