Managing the Complexity of Content Management

by:   |  Posted on

“Where’s the disconnect between what’s possible and the too-often failure of CMS?”

Content management systems suck. Or so you would think from the strife heard from analysts and practitioners alike. And yet, many websites regularly publish vast amounts of information with superior control and ease compared to manually editing pages. So where’s the disconnect between what’s possible and the too-often failure of CMS?

Our experience with content management systems

To discover what kinds of problems people are having, I surveyed other practitioners. The survey was conducted in late January 2003.1 Participants of Sigia-l, AIfIA, and the ia-cms list were invited to participate. A total of 64 responses were collected. Figures 1 and 2 summarize the results. You can also view the complete survey results online.

As you can see, the issues are many, spanning strategy, design, content, technology, training and several others. One conclusion we can make is that content management has become a very large category—attempting to include content authoring, metadata authoring, database-backed websites, workflow management, and even thesaurus management—and instead of making CMS a goal you might start by focusing on which of these functions you need. Otherwise, the general complexity becomes the central problem facing any content management project.

Managing complexity

Martin White, a CMS consultant and writer, writes in EContent magazine, “A CMS is probably the most complex rollout you and your IT colleagues are likely to have to manage.” This is because content management most likely requires contributions from many different skill sets and coordination across diverse departments and roles. A CMS project can cost hundreds of thousands or even millions of dollars and require months or years to design and implement. Because of the high planning, purchasing, and design costs, there is a need to effectively manage the complexity of CMS projects. I’ve seen some organizations do this well and others not so well.

Here are ten lessons in managing complexity gleaned from real-world, successful CMS projects. Ideally you’ll consider these at the beginning of a project when they can have the most impact:

  1. Keep the team small.

    A big team usually requires a lot of coordination and communication, especially if it is spread across different departments, offices, or cities. This coordination increases the points of failure and quickly reaches a level of diminishing returns for systems that need close collaboration to be designed well.

    To overcome this problem, one financial services firm formed a multidisciplinary team of only five experienced people to create their content management system. The team included people who both had skills to contribute and could make executive decisions. This team consulted with additional, specialized staff only when needed. In the end they succeeded in building a system in a few months in a company where other efforts typically spent several months and failed.

  2. Don’t try to fix everything at once.

    A CMS alone is complex enough; combining that effort with a site redesign, new workflow, new content, and more may be asking for trouble.

    An international retailer decided to expand their content management system in a way that required multiple new software packages. To reduce complexity, they swapped in the new CMS without changing the design of either their online or print catalogs.

  3. Only build what you need.

    It’s important to remember the main benefit of content management systems is efficiency. Anything done with a CMS can be done without a CMS by people with the right skills, albeit in much less efficient ways. Websites often use content management when there is a large volume of content, frequent content updates, content distributed across several media, and so on, tasks that would be arduous when done manually. But if more effort is needed to implement a CMS than to manage the content manually, the return on investment is quickly lost.

    The potential features of CM software spiral out in all directions, so discipline is needed to decide which features are needed most. At the beginning of a project we can examine which features bring us the most benefit compared with how difficult it is to implement those features, and choose the features with the most value.

    A new media group at a bank took this approach and built the absolute simplest CMS that would serve their needs, and then gradually added one feature at a time as the need became clear.

  4. Create an efficient information architecture.

    A content management system with a different template for every published page would not be very efficient. And if efficiency is the main benefit of a content management system, then it makes sense to use fewer templates. As designers, we must be very clever about how to arrange diverse information into a small number of templates while still retaining some flexibility in the presentation.

    A large technology company achieved this efficiency by creating templates as well as reusable modules of information—such as a list of related links—that fit inside those templates. By creating rules that determined how templates could use certain modules the company struck a balance of CMS efficiency with display flexibility.

  5. Show your content some love.

    Of all tasks in a content management project, the creation, editing, and migration of content are probably the most frequently underestimated on the project plan. The survey above reveals this void as the biggest problem with CMS. Amid much sexier design and technology issues, the creation and/or re-formatting of content can be delayed until this eventual necessity delays the project.

    To counter this problem, one non-profit organization settled on an article layout at the beginning of a project so it could start preparing the content earlier, then continued the content work in parallel with the design and technology work.

  6. Hire bouncers as project managers.

    Perhaps this is going a little too far, but you do need rigorous project managers that understand CM issues who will babysit the team to make sure every little task is getting done. These project managers must do more than make sure documents are delivered on time, they must help connect the work that all team members do.

    One large retail firm took this to heart by using two project managers: one to oversee the business and user interface issues and another to oversee the technology issues.

  7. Tightly integrate design and technology.

    Content management software involves certain components, such as content entry screens, that require a combination of interaction design, information architecture, writing, and database programming skills. Few people do all these things well, and having different people or groups design these components in isolation risks poor quality and consistency.

    My smoothest experience designing these components was when my desk was located right next to the programmer’s desk and we constantly discussed the design as it evolved.

  8. Buy the right size.

    In the survey cited above, the number one problem with software is the expense. You might think the solution to this problem is to buy a less expensive software package, but I think a better solution is the buy the right size software package.

    Tips for choosing the right software:

    • Buy small software if you’re a small organization. Organizations like Boxes and Arrows, the Asilomar Institute of Information Architecture, and Adaptive Path all use Movable Type to manage content, which was originally designed for weblogs. As content management software, it doesn’t provide many basic functions, but it simplifies the publishing process enough for occasional publishing needs.
    • Buy big software if you’re a large organization. One big CMS can actually be more efficient than many different, smaller packages. One financial services firm employs a federated model of CMS by using one software platform to publish many websites, avoiding the extra training and technical work needed to work with several different software packages.
    • Buy no software at all if you really don’t need it. In the decision to buy vs. build, we can also avoid software all together.
  9. Design faster than business can change.

    You must design and implement your system faster than your organization can change.

    For example, a large computer networking company found that it required three years to roll out a new website design across all its departments and websites. Before they could finish, the organization had undergone significant changes that needed to be reflected in a new site design. Designing fast may mean keeping the scope small, but it can also mean finding innovative approaches to problems rather than simply following conventional methods. Building a Metadata-Based Website is an example that speeds design of very large sites by focusing management on the business concepts instead of the content.

  10. Get a second opinion.

    Content management is an elaborate, dynamic field and there are several solutions to any problem. Just as in medicine, it’s sometime necessary to get a second or third opinion to hear approaches that arise from different philosophies.

    One international retail company brought in a CMS expert to consult to the team without doing any of the work herself. As an expert who didn’t work for the company or any of the contracted vendors, she was in a good position to provide impartial guidance. As a disinterested third-party, the expert can help smooth interaction within the team while leveraging experience from previous projects.

Now you have a list of problems others have had and ten ways to address the complexity of content management. Will following this advice solve your CMS problems? Not entirely. If you’ve only heard the hype from software vendors, you may have very high expectations that need to be reconciled with reality. Content management systems are not a silver bullet, but they can make your most onerous tasks more efficient if you actively manage the inherent complexity.


  1. The survey was conducted January 24–31, 2003

Victor Lombardi writes, designs, and counsels, usually in New York City. His personal website is

The Evolving Homepage: The Growth of Three Booksellers

by:   |  Posted on

Web design is expensive. Web designers earn upwards of $50,000 a year1, information architects earn even more.2 During the heyday of web design—the late 1990s—designing a large commercial website could cost as much as designing a medium-sized building. During this period, commercial websites were created and then often completely replaced with redesigned versions a short time later. Today the redesigning continues, albeit at a slower pace. What is the return on this design investment? A report on online ROI from Forrester finds that many commercial sites fail to even try to measure the effectiveness of design changes.3

What lessons have we learned about how design improves the interface between customers and companies?

The web has been with us for about a decade now. We’ve seen some obvious trends, such as greater use of multimedia, search engines, and increasingly sophisticated markup techniques. But these trends were facilitated by changes in technology. What lessons have we learned about how design improves the interface between customers and companies? Perhaps we can start by asking how websites have actually changed over time, and from that we can learn how websites should change in the future.

To start working toward an answer, I compared three eCommerce sites:,, and Much of the media’s coverage of these websites, especially coverage of, discusses the business models, corporate cultures, and finances of the companies. Since the medium of interaction with these companies is the website, it’s ironic that the media rarely critiques the site design and its effect on business performance.

Because it is the homepage that carries the most responsibility for guiding customers, I examined the homepages of all three sites from a number of years, using screenshots from the Web Archive4. Presumably these large retailers had a great deal to gain, and lose, with these substantial online ventures. By comparing design decisions over time among the three sites, I hoped to discover lessons from their extensive and expensive design experience.

The companies
Competition is fierce in the online bookselling market, currently erupting in offers of “free shipping.” All three companies have annual revenues in the billions of dollars.

Barnes and Noble, which runs a large chain of stores in the United States, claims the largest audience reach of any bricks-and-mortar company with Internet presence.5 Yet, both they and Borders were put on the defensive when Amazon’s growth rocketed. During December, 2001 attracted over 10 million unique visitors,6 compared to Amazon’s 40 million visitors.7

Borders is the second largest bricks-and-mortar book chain in the U.S. 8 In April 2001, after operating their own online bookstore for several years, Borders announced an agreement to use Amazon’s eCommerce platform to power a co-branded website.

Amazon claims to be the leading online shopping site, having expanded their selection to music, video, auctions, electronics, housewares, computers and more.9 By February of 2002, Amazon, which had pursued a get-big-quick strategy typical of internet companies in the late 1990s, announced its first profitable quarter.10

I first studied these sites quantitatively looking for clear trends over time. I then critiqued them in a more qualitative way based on my own experience as both an in-house website designer and as an information architecture consultant.

There are many criteria that could be examined in such a study. I limited myself to those that would, I hoped, reveal as much as possible about the business intent of the design. I looked at criteria such as the type and size of layout, the type and amount of navigation, the amount of images and text, and functionality specific to the industry. Detailed results can be seen in the attached spreadsheet (PDF, 75k).


Chart showing growth in length of homepages over time
Click to enlarge.
Note: Missing data due to imperfect records at the Web Archive.

All three sites use very long screens to display content on their homepages.
Using a browser window with a constant width, we can compare the vertical size of each site (all screen references assume an 800 by 600 pixel monitor). The homepage grew from a vertical size of about 917 pixels in 1996 to over 3,000 pixels in 1999. Barnes and Noble’s homepage has hovered around 1,500 pixels for the last several years. Amazon’s homepage, which began at only 626 vertical pixels in 1995, stands at roughly 2,156 pixels today. In a web browser, that equals five scrolling screens of information. homepage above the fold, 1999 above the fold (1999) Click to enlarge.
Barnes and Noble homepage above the fold, 1999
Barnes and Noble above the fold (1999) Click to enlarge.
Amazon homepage above the fold, 1999
Amazon above the fold (1999) Click to enlarge.

Note: Incomplete web pages are due to imperfect records at the Web Archive.

All three sites evolved to use three-column layouts.
In 1995 and 1996 respectively, Amazon and used single-column layouts. By 1999, both of these sites as well as Barnes and Noble used three column layouts.

Amazon has consistently placed more links above the fold.
In 1999, the Borders site displayed only about eight links “above the fold” (the top portion of the screen that is viewable without scrolling). Both Barnes and Noble and Amazon had significantly more links above the fold in 1999, 30 and 48 respectively. Amazon averaged 43 links above the fold between 1999 and 2002 versus only 27 links for Barnes and Noble during the same period.

Through the years, the density of links on was half of that on Barnes and Noble or Amazon.
The density of links has varied over time, but as of 2002 both Barnes and Noble and Amazon stood at about one link for every 15 vertical pixels of screen real estate. Historically, the highest link density at was one link for every 28 vertical pixels.

Amazon communicates using images and links rather than text descriptions.
From 1999 through 2001, Amazon used more images and fewer text descriptions than Barnes and Noble. In 2002, both sites used about 560 words per page, yet the density of words was 33 percent lower on Amazon; Amazon distributes the words across the page as links rather than bunching them together in paragraphs. Over time, Barnes and Noble is becoming more like Amazon in this respect.

All sites eventually included navigation targeted at specific audiences.
Audience-based navigation—navigation labeled for a particular audience—appeared on in 1998, on Barnes and Noble in 2000, and on Amazon as early as 1999.

Invitations to subscribe to an email newsletter were offered inconsistently. didn’t include this feature until 1998. Barnes and Noble included it only in 1998 and 2001. Only Amazon consistently included this feature from 1995 to 2002.

Online and offline design
So what lessons can we learn about how these sites changed over time? How has design contributed to Amazon’s high growth and significant lead over the others? In general, Amazon found a winning formula and applied it consistently over time. In my mind, the successful design elements emulated offline shopping experiences in many ways.

Personally, I was surprised at how long these homepages had grown. Combined with the three-column layout, each page contains a great deal of information. This is quite like the perceptual experience of browsing in a physical store. When you walk down an aisle in a bricks-and-mortar store you can visually scan the shelves quite quickly. On these websites, the long, scrolling pages are analogous to aisles (major groupings of items) and the columns are analogous to shelves (more specific groupings of items). With a similarly natural, efficient motion, a visitor can scroll down the page and visually scan the three columns of product listings.

Amazon homepage
Amazon homepage
(January, 2002)
Click to enlarge.
Barnes and Noble homepage
Barnes and Noble homepage
(January, 2002)
Click to enlarge.

Amazon’s higher number and density of links, and placement of those links above the fold, also reminds me of the aggressive product positioning in a physical store. It’s like walking into a food market and immediately being overwhelmed with rows and rows of colorful fresh fruit, stimulating our eyes and engaging our appetites.

The prominent use of images and sparse use of text on Amazon again harks back to physical objects with simple labeling.

The arrival of navigation intended for specific audiences seemed inevitable. Especially for the book market, a children’s section was developed surprisingly late on these sites given the disproportionately high revenues that come from children’s books in traditional shopping venues.

In general, many of the functions of these pages have become commodities: search engines, shopping carts, authentication and store locators. But Amazon’s extensive personalization sets this site apart functionally. Personalization mimics a personal shopper or a local store employee who knows you. While the online recommendations aren’t always right on, neither is a human assistant.

Rate of change
Many studies have found that our performance using a software application improves over time as we become familiar with its interface. Gerald Lohse and his associates translated this finding into the realm of eCommerce websites using statistical analysis.11 They also found that website visitors learn to use a site more efficiently over time and that this increases their purchase rate. In simpler terms, it means familiar sites are easier for people to use, so familiar sites are where visitors will make purchases.

It follows that sites that can be learned more quickly will more quickly become familiar, increasing the amount of purchases. So a faster learning rate equals a higher purchase rate.

Furthermore, Lohse found that familiarity with a particular website makes visitors less likely to switch to a competitive site because of the effort and time needed to become familiar with another site. He refers to this behavior as “cognitive lock-in.” Essentially, we are creatures of habit. He applied this analysis to several eCommerce websites by measuring the number of visits per person, length of sessions, and timing and frequency of purchases. He found the learning rate significantly faster at Amazon than at Barnes and Noble.

The rate of design change supports this finding. Amazon had no major redesigns from 1999 to 2002, only adapting their design gradually to changing needs. Barnes and Noble significantly altered their navigation in 2000 and 2001. implemented major homepage changes in 1998 and 2000. Fewer redesigns make it easier for visitors to remain familiar with the site.

Many design elements on these websites are reminiscent of physical store layout, an approach to web design we should investigate further. Like physical stores, those designs should only change gradually to keep visitors buying. Continued analysis of other sites will hopefully help confirm or deny these findings.

It may be a fallacy to state, “Amazon is a successful business, therefore their website design is successful,” since many factors have contributed to their business success. And yet it’s hard to imagine them having such great success with a mediocre site. A similar eCommerce site launching today could do worse than examine and emulate the design elements that Amazon utilizes.

View all End Notes
Victor Lombardi writes, designs, and counsels, usually in New York City. His personal website is