View All Tips

Content Analysis

Last month we provided a brief overview of single sourcing, noting that while it is an excellent concept, the key to the success of single sourcing is investing the time and expertise to organize information appropriate to your organization's needs. This critical effort means significant work up front—which often conflicts with the demands of production schedules, not to mention budget. To create meaningful content objects, you have to stop producing content. You need to step back and analyze, organize, and categorize content in a way that works for multiple users, for now and for the future.

This month's Tips focuses on content analysis. Clearly, this is not a subject we can cover in depth in a newsletter. What we can do is discuss the basic requirements and steps in the process, and how to get started.

As with all projects, we recommend that you start small. If you have a dedicated publications department and unlimited budget, you can start with a grand plan. However, failing that, start by selecting a small, discrete set of material. For example, you might start with a set of procedures, a short user manual, a booklet of corporate policies. This allows you both to achieve some immediate success to build on, and to learn from your mistakes and (hopefully) to avoid repeating them. To get started you need the following:

• a reliable style guide used by all content developers and editors
• a clear understanding of the document family
• content knowledge—this includes an understanding of the current product or process as well as related, past, and future versions
• knowledge of the audience and how they use the material
• tool(s) to record your analysis

A reliable style guide ensures that everyone is using identical terminology. For example, the same document should not be called a guide, a manual, and a book. A style guide dictates identical format for identical uses, spells out what heading levels mean, and in general serves as the initial blueprint for content analysis. If you don't have one, creating one is the first step, and aligning your documents to it is the second. Do this before proceeding—standardization of content is a key requirement for single sourcing.

Next, review the material in light of your knowledge of its context and use. Think about how to divide the elements. Most technical information has a basic structure. For manuals and guides, this is the existing table of contents (TOC); for online help systems, it is the list of topics; for web sites, the site map. These hierarchical representations of the content are typically a good starting point for analysis, though you usually need to be more granular than the typical TOC in developing chunks. First divide information into major topics (leveraging this existing structure).

Next, under each major topic, look at the content itself. Think about the smallest meaningful unit. This might be an introductory paragraph, a series of numbered steps, or an entire descriptive section. You need to categorize information by content type. The type designates the specific user behavior the content addresses. For example, you might start with a simple system of three content types: concepts, tasks, and features.

• A "concept" chunk helps the user understand and internalize something fundamental to the product or technology. Introductory paragraphs, overviews, and descriptive information are examples.
• A "task" chunk prompts the user to follow a particular set of steps when using the product or technology. Procedures, numbered tasks, and specific directions on how to do something are examples.
• A "feature" chunk helps the user understand a specific attribute of the product, process, or technology. Sales information and specific details from conceptual overviews or tasks are examples.

There is no rule about how large or how small, although the larger the chunk, the more limited the reuse. For example, a whole procedure might be a chunk, complete with introduction. Or the introductory paragraph might stand alone for multiple uses, with the procedure separated off. The procedure itself might have discrete, reusable portions. This is especially true of steps that relate to a product with many versions.

Once you analyze the content, determining the smallest reusable chunks, you then need to edit based on your analysis. Once again, this ranges from saving files with specific naming conventions to match your content analysis, to placing hidden or conditional text inside one large document, to saving chunks in a database or CMS.

You also need a tool to record your analysis; this can be as simple as paper and pen or as complex as a content management system (CMS). Excel spreadsheets work fairly well as a starting point for a small document set.

Bottom line, you don't have to invest hundreds of thousands of dollars to start preparing for single–source documentation. You can institute this disciplined practice with every document you develop. This approach gives you a huge head—start on single sourcing.

Next month we'll take the process one step further—how to start the process of organizing and reusing chunked information.

(A special thanks to Bruce Overby, a consultant TechProse has been working with on single sourcing, for his review and input on this topic.)