Designing a Content Management Workflow

(Originally written on July 31, 2008)

Overview

Although all corporations have business processes that complicate workflow (for example, because of legal issues, or historical business reasons), a process that is mapped out in detail and vetted with all responsible parties as a part of the business requirements will help make the implementation of a content management system much smoother.

The following is an example of a process workflow that, although somewhat generic, can be adopted for a number of content types and organizational structures.

Organization (Process Workflow)

Typically, the design of a workflow process starts from the perspective of the “types” of people working within the system. These “types” (or roles) represent the different permissions or privileges that can be performed by those users on different content objects.

When generic descriptions are used (such as “actors” meaning “people who act within a system”, or “content objects” meaning “things that represent the content that will be manipulated or displayed — such as a text article, an image, a set of images, a combination of text and images, video, Flash movies, etc.”) it makes it much more difficult to understand how a system needs to be implemented. It helps to imagine a generic article (composed of text and images), such as a blog article or a news posting, as the “Content Object” that is being manipulated in the following diagrams.

Likewise, the roles being used below are placeholder names for whatever roles are within an organization that perform the following tasks:

Copywriter: This is the person who creates the initial “copy” or submits the initial content for the system. They can be either internal or external (for example, a freelance journalist) which is why they have very few permissions.

Channel Manager: The next level of person is someone who would manage a “channel” of content — such as “sports”, “movies”, “fashion”, etc. This allows for people who have a particular area of expertise to control their area, without getting involved with or distracted by all other content in the system.

Content Manager: In a newspaper or magazine, this would be the Editor-In-Chief, the person (or in this case people) who are primarily responsible for the overall live publication of content.

An additional role of a Researcher is not represented below, but an example of a Researcher would be someone who would be able to access the system and read all articles within the system, but would not be able to change their state.

The following figure shows the states that a Content Object can have when under the control of a Copywriter:

There are three states: Create, Draft, and Submit.

Create allows the user to create a new article. It is not really a state within the system (blank articles wouldn’t be allowed in the system) but it helps to represent the beginning state — such as when the form fields are being filled out on a screen.

Once the article is submitted, it would be saved to the database in a Draft state. Any successive edits and saving will continue to save the article in a Draft state (representative by the arrow coming from and pointing to the Draft state in Figure 1).

The Submit state occurs when the Copywriter is finished with the article and is ready to submit it to the next stage of peer review. This takes the article out of the Copywriter’s hands, and into the Channel Manager.

In this workflow, roles are inherited. This means that a user with a higher role can perform all of their functions as well as perform the functions of any lower role. The Create, Draft, and Submit states can all be managed by Copywriters, Channel Managers, and Content Managers. They may not be able to see each others articles (those permissions will be set per user) but they will each be able to start an article from the Create state.

Figure 2 shows how a Channel Manager takes an article from the Submit state, and is able to Review 1 it (which, like Create, is not a state per se, but is a function that the Channel Manager is able to perform). This allows them to view the article.

Then, they will be able to Reject 1 it (with comments, for the original Copywriter to edit in Draft mode and re-Submit), they can Edit 1 it themselves, or they can Approve it, which will pass it on to the Content Manager.

The reason there is a distinction between Edit 1 and Edit 2 (or Reject 1 and Reject 2) is because the state of a Content Object (in this case an article) will need to be kept up to date. It would be much more difficult to retrace the steps of an article or track changes, if the article was simply in “Edit” mode — we wouldn’t know exactly where the article is in the system without specifying these distinct states).

Once the article is Approve-d, the Content Manager (or Editor-in-Chief) is able to Review 2 it, and then eitherReject 2 it back for editing (with comments), Edit 2 it themselves, or Schedule it to be launched.

The Schedule task (as well as Expire and Unexpire) are more relevant for information that needs to be published at a certain time (such as for an “issue” of a magazine). This process could instead go directly from Review 2 toLaunch, and then allow manual expiration back into the Edit 2 state (if time-based scheduling is not needed).

Content Management Team Structure

Based on this process flow, the entire system could actually be managed by a single person (who had the role of Content Manager).

As more content is entered into the system (or based on business requirements) a new person could be added and given the role of Copywriter. Then, as they became more familiar with the system, they could be given the added responsibility of a Channel Manager. New people could easily be added to or removed from the system.

When this system was implemented for a major international corporation, the team managing content in the US consisted of about 12 people (three Content Managers, six Channel Managers, and four full time Copywriters, as well as additional content coming in from third-party Copywriters). A version of the site was created for Mexico, which was entirely managed by only one person. Three months later, when their site had more content as well as more users, three additional people were brought on in Channel Manager roles to develop additional content.

Content Management System Usability

Although users of a content management system are usually internal people, there are still usability issues that should be addressed, in order to ensure adoption and usage. (If users are forced to use a system that they don’t like, their work will suffer and they will be likely to abandon it at the first opportunity)

One important question to ask is: how technical are your users? Can they edit text fields as html (manually creating inline links) or will they require some sort of rich-text environment for editing text?

Don’t forget: the more functionality you add, the harder is it to train someone and the more potential bugs are introduced.

For example, a text field that accepts html marked up text is pretty easy — it’s a standard textarea form field, and it just saves anything inside of it to a database. Adding a panel for that text field that renders fonts, links, and inline images makes things easier for a less technical user, but may cause problems on different browsers and may make it slower to load each screen of the Content Management System.

This usability and functionality trade-off also impacts training and usage. The easier it is to get in and get out of the system, means it’s more likely for a user to continue to use it.

Conclusion

It is easy to talk about building a content management system by saying “certain users will enter content, and we’ll launch it on the site”, but once it comes to the actual implementation, a lot of companies get bogged down in processes and procedures that end up making the content management process more inefficient than the system they are replacing. Defining a process, roles of the different users using the system, and how content itself moves through a system — and making sure that these are approved by all business owners — goes a long way toward ensuring adoption and usage of a solid and robust content management system.