Making Your Content Management System Work for You: An Interview with Jeffrey Veen

by Christine Perfetti

Adaptive Path’s Jeffrey Veen is a recognized expert in the area of Web Design and Content Management Systems. UIE’s Christine Perfetti recently had the opportunity to talk with Jeff about the reasons why many content management systems fail and what designers can do to avoid the common pitfalls associated with CMS installations. Here is what Jeffrey had to say about his experiences.

UIE: You’ve described the web as a medium for publishing content and recommend designers view and treat their public-facing web site like a publication. Is this publication model a mindset change for most designers?

Designers? No. Most Web designers still have roots back in the world of print. They are familiar with editorial processes, quality content, and visual design’s importance in communication. Most designers I’ve worked with know how publications come together and understand their own role in the process.

Most often, I find that businesses don’t treat their web site as a publication, especially those organizations developing standard content, such as product and service descriptions. Instead, they view their site as a software project—a product that undergoes a development process and needs to be “released”. Parts of a web site development project work this way, such as search engine upgrades. Yet, most users aren’t concerned with these parts—they are focused on the content.

For example, I recently helped a company migrate to a new content management system. In my interviews with the content creators, they told me that problems, such as spelling errors and fact changes, required them to open a bug-tracking system ticket. Once the issue was report, they typically had to wait four to six weeks before the problem was “resolved.” Like many companies, they consider their web site a software project and not a publication.

We’ve seen in our work with clients that many websites don’t need a CMS to be successful. At what point should a development team consider moving to a CMS?

For many companies, they should probably never consider installing a CMS. After looking at the resulting implementations of dozens of CMS packages, it’s pretty clear these systems are grossly bloated with complex features few sites need.

Most CMS software evolved from the Document Management process, which involved the development of large, complicated documents that hundreds of people collaborate on. These Document Management systems were excellent at enabling collaboration for situations like new drug approval or oil-drilling exploration. These documents are often thousands of pages long, with a complicated legal approval process. You don’t want to screw that up, for sure.

However, 90 percent of the web sites don’t need the complex features of a CMS. Most only need a way to move the page maintenance to the responsible people. For example, if an organization wants the marketing department to control the site’s press release area, the marketing folks need a mechanism to get content online immediately, fix mistakes, and take down outdated information. They don’t need to contact the technical services department for this.

You’ve seen that most CMS installations fail within the first year. Why?

For two reasons, really. First, a CMS is almost never a piece of software that you can buy and start using right away. Rather, they are platforms—frameworks for building custom content applications based on an organization’s needs.

Second, the editors, writers, designers, and managers who run departments are not software engineers. They don’t speak the same language as engineers. They don’t know (or care) what the “content-module lifecycle parameters” are.

So a big CMS project gets developed as a software project rather than an editorial process and the technical folks point fingers when it fails, “Well, we didn’t have good requirements from the content people.” That’s not true. They just didn’t ask them the right questions.

The perceived costs have kept many development teams away from installing a CMS. Does content management have to be expensive? Are there inexpensive tools that provide robust content management?

That’s actually a pretty big misconception in the industry. Content management isn’t a software problem at all. It’s a process problem. By solving process problems, you often find you don’t even need software. Many companies buy software thinking that it will fix their process problems. But that’s like buying Microsoft Word hoping that it will make you a better writer.

Rather, development teams need to create a content strategy that answers several questions:

Why are we generating this content?
Who is the content for?
What is the current user workflow?
How do we get the content into a database?

If development teams have good practices for answering the first two questions, then it’s not important what database or template language they use. Inexpensive solutions, such as PHP and MySQL, are fine for 90 percent of sites.

What factors should teams consider when choosing the right CMS for their needs?

My most-frequent response to this question is, “What’s the absolute least you can get away with?” Initially, teams should get the super-simple solution working and, only then, start adding complexity.

What roles does the development team need for a successful CMS project?

Development teams should remember: a CMS installation is an editorial project, not a technical project. The team needs an engineer, but only as a consultant to provide reality checks. The most important roles on the team are the editorial director and the metadata specialist. It’s also essential to have a project manager to keep the project on track and to ensure everyone who uses the CMS is involved in the process.

Many of our clients are currently trying to personalize the web experience to create unique experiences for each user. Do you believe there’s a need for content management systems to personalize pages?

This is another strategy that will result in a CMS project failing. It is really hard to install a CMS. The CMS migration is expensive, intensive, and risky. But so often, I hear from designers, “Since we’re tearing everything apart for this project, why don’t we redesign and add personalization? We can also get a mobile device strategy going and hook it into our accounting systems.” Suddenly, a project, whose purpose is enabling people to edit web pages, evolves into a multi-million-dollar corporate web strategy rethinking.

My advice is to do the simplest thing first. When that works perfectly, do something a little harder next. Then just keep repeating. But the quicker you launch something, the more internal buy-in you’ll start to get.

Adaptive Path has conducted in-depth research on the ROI of User Experience. Do you have any recommendations for how a design team can justify the investment in a CMS?

That’s a difficult question. It’s hard to measure the value of getting your pages online quickly and keeping them accurate. Of course, there is tremendous value as an out-of-date web site reflects terribly on an organization. But measuring the value isn’t as easy as watching shopping cart abandonment go down.

One major value of a CMS investment is the increase in employee efficiency and efficacy. If employees get their jobs done faster because of a streamlined process, then an organization will definitely save money. But, according to managers that I’ve spoken with, saving money and making money are very different things. Increased revenue shows up as a hard number on balance sheets. Efficient employees don’t, at least not explicitly.

So your employees are empowered to do good work, they stick around longer, get their job done faster and with fewer errors, and your web site does a better job of reflecting your company’s leading position in the market. Pretty good, if you ask me. I just can’t give you a dollar figure for all of that.

Thanks, Jeffrey.

Published here on September 29, 2004.