Content? Or Dis-content?

In: Articles

By Garth A. Buchholz, BA, CUA

Published on August 21, 2003

Whenever I’ve been involved in major Web start-ups or redesigns as an information architect, one of the biggest vocabulary challenges involves two of the simplest words: content and design.

To many, content is the gift while design is the shiny giftwrap around it; content is the cargo in the back of the truck while design is the truck’s shape and appearance. Subject matter experts in our organizations create “content,” which usually means text and numbers, then shovel it down to the Web designers to create the “look and feel,” which usually means colors and graphics. This can create a crazy loop of miscommunication and revisions when business leaders/clients start to realize that each design attempt actually changes the way the content will be used and received. In fact, designers have always known that design and content are, ultimately, interlinked. Change one, you change the other.

Not a virtual library

In spite of the quaint simile tossed around in the ‘90s, we realize now that the Internet isn’t a big, online library, although there are many libraries within it. The book/library paradigm is white-haired, wrinkled, and about a hundred years out of date. Twentieth century broadcasting and 21st century Internet publishing have accelerated the convergence of communications, design, and functionality to a nexus where, as McLuhan observed, the message and the medium are becoming indistinguishable.

This applies to our paradigms for dynamic content as well. Content isn’t a nut inside a shell, or an ore within a mine. Yet content management companies are still developing ways to package and publish documents online within templates, shell designs, page-lets, etc. Database companies are still mining content to generate dynamic Web data in different formats. Everyone wants to sever content from format without examining how that content is being changed in the process. Look at some of the cookie-cutter ways content is being published on the Web to see the result of thinking of the Internet as a content vending machine rather than a dynamic, complex organism that, like the Escher drawing, is really a hand painting itself.

Content management gurus biased

Even many content management gurus seem to have this bias toward defining content as text and documents. Consider the etymology of the word “content” from its Latin roots: “contentum” —to contain—and “continere”—to hold together or enclose. We think of content as something within something else. Yet content is, strictly speaking, not something you drop into a package, but the package and the substance within it. In other words, you cannot separate pure substance from its form. Alter the container, and you alter its essence. Deconstruct the content’s form and you begin to disintegrate the content itself. It’s out of context, or what I call “contextual dissonance.”

This means graphic designers and Web designers must be entitled to play a more integral role in the content development process, so that content + design become one concept: “content design.” And the way to do this is to start taking a leadership role in how content is planned and developed.

Developing a Content Requirements Plan

The most effective way to start researching and documenting your content design strategy is to begin with a solid Content Requirements Plan (CRP). This enables you to develop a content design strategy so that your Web design efforts are driven by content requirements and supported by your business leaders or clients. A CRP is a project management-style foundational document to guide every aspect of content, design, development, and measurement for Internet projects.

Here are the elements to a Content Requirements Plan (CRP):

PART 1: Project Information

Project title

The working title or actual name of the Web content you want to develop.

Project leader(s)

The person on your team organizing and leading this project.

Project owner

The department or team responsible for approving and maintaining the content for this project.

Project sponsor

The department or team responsible for providing the resources and budget for this project.

Project stakeholders

The individuals, teams, or departments that also have a stake in this project and must be consulted.

PART 2: Pre-project planning

Charter

State objectives for this content in order of priority (can be as many as necessary). Statements should be high-level and should be stated as an action, e.g. “To provide a learning environment for students; To offer services to the public; To create a virtual store where people can purchase products online,” etc.

User Profiles

State target audiences in order of priority (can be as many as necessary) and provide a brief profile of each. Who are you trying to reach with this content? Who are the other people or groups that will use your site?

Description of Project

Describe content and how it should be used on your site. Suggest possible navigation schema or how content could be organized. Web site standards and usability issues should be addressed.

Critical Dates

List any critical or key dates for this project (can be as many as necessary), such as latest date for completion, translation dates, approval dates, etc.

Virtual Location (URL)

Indicate the URL of the Web presence.

High Level Requirements

Indicate the high-level requirements for this content. This information should be fairly general and should emphasize what the end uses or outcomes will be rather than how it will be implemented (i.e. specific technology solutions).

Content Assessment

Include a Content Inventory, which is a spreadsheet that lists information such as:

• what content objects will be developed;
• the type of each content object and a brief description;
• which content objects are new and have to be developed;
• who will develop each new content object;
• which content objects exist in some form already;
• which form the existing content is in now;
• who is responsible for each content object; and
• the level of importance for each content object.

Depending on the amount of information, this information can be captured here or submitted as a separate document.

The Content Assessment lists:

• key content categories or descriptions
• their relative priority level to the overall project
• whether all content is to go-live simultaneously or in separate releases/stages
• key stakeholders for each
• other factors, such as environmental/market timing issues

This information may be part of the Content Inventory or on a separate spreadsheet tab, depending on the amount and complexity of content. It enables the business leader and the designer to establish whether the content can go live at the desired date, given existing resources, or in separate iterations so the initial go-live date isn’t delayed.

PART 3: Post-Project Planning

Sustainability & Resources

Include information on how the content will be maintained, what resources will be needed, what some of the challenges will be, how the physical environment will be set up (how the files will be named and organized in document folders on the server), how often content will need to be refreshed or replaced, etc. Indicate how usage will be measured (i.e. number of hits, etc.)

Other risks/factors impacting the project

List other internal or environmental factors not included above, including a risk assessment, if necessary.

While this seems like a high level of detail to gather, I recommend completing this CRP and a Content Design Strategy as thoroughly as possible prior to embarking on a major Web design project, and as one of the first steps in a project plan. When I teach small groups of students to complete CRPs in a classroom setting, they discover that an hour’s worth of collaboration on a CRP is invaluable in helping them plan their content design strategy.

Related Topics: Content