Multipublishing in Corporate Communications

Multipublishing is a term I use to describe the publication of the same information in more than one place in corporate communications. Multipublishing is neither good nor bad, in and of itself, it is simply very expensive and dangerous to maintain. Why? Because it is absolutely critical that this multipublished information be consistent throughout the communications otherwise an inconsistency constitutes and error, which causes doubt about the product/service and about the company in the customers' and public's eyes. It can and often does lead to loss of revenue or, in extreme cases, even legal proceedings against the company.

Scary: Multipublishing inconsistently, however damaging it can be to a company, is the rule rather than the exception that I've found in my 20+ years of experience as a technical writer/editor. As a rule with few exceptions, no one manages specifications, requirements, a lexicon, and a style guide with for communications about products/services, and even if such is developed it is not shared with all parties who need to know about it.

This article seeks to persuade you of the following:

* To minimize multipublishing.

* When multipublishing is done, to ensure that it is done consciously and conscientiously, such as from a master boilerplate document or by cross-editing ALL content pieces associated with the product (pre- and post-sales, web, tech support reference documents, and so on).

* Minimizing and coordinating, through a specifications and boilerplate document, multipublishing to increase the speed with which documentation can be completed, increase the accuracy of the documentation by reducing inconsistencies, minimize the impact of maintaining the product documentation in the future, and most importantly increase the customer's trust of the company and its products and services due to consistent messages across the product's content pieces.

Let us consider the case of a product sale, since products are generally more concretely documented and more easily understood by most people than processes. However, the phenomena of multipublishing is just as prevalent in process providers (insurance sales, home sales, shoe sales, consulting services, and so on).

Information about the product is written for numerous reasons, including:

• product documentation (user's guide, maintenance guide, interactive education and support DVD)
• sales literature for the product (sales sheet, product spec sheet, price list)
• advertising of the product (print advertisement, brochure)
• trade-show give-aways for the product
• training class material
• website text
• documentation (book, binder, reference guide) cover
• packaging
• ... and many other possibilities, including a big one:
• translation of text into other languages and data transferred to or from the metric system!

Each of these items, and any others that are developed, might be created by a different person: technical writer, marketing writer, advertising writer, product manager, programmer, user experience engineer, user interface designer (for software products), website developer, and so on.

So, content creators: be aware and beware of multipublishing! It needs to be handled with extreme care. Be sure to establish a central requirements and specifications document that includes information about the specifics of the product and how they should be discussed. All written/spoken parts of the product should go through the same requirements gathering, specifications development and documentation, and QA processes right along with the core product itself, whether it is a widget, process, or service. This, and continual communication between content developers across the company, is imperative to ensure consistency: the product photo must match the one described in the text, the construction and color must be the same, the functionality of each button or lever must be the same, and so on.

Note that the example about translation illustrates a case in which "information"--not just the identical text--is published in more than one place. Although publishing the exact same text in multiple places is certainly one type of multipublishing, the term really includes all pieces or "chunks" of "information", whether that information is relayed in the same manner in each delivery method or not.

Multipublishing has consequences that may not be obvious at the time content is created. This article discusses various types of multipublication in product information content and the short- and long-term consequences of it.

In this way, product information content developers will better know how to judge what should be multipublished and what shouldn't. It's very easy to cut-and-paste information from one place to another, yet in product documentation usually "less is more". Also, the unique nature of product documentation development presents some specific challenges with respect to multipublishing that may not be present in other types of documentation (process, service).

Any person who creates text or graphics or software code related to a product might be involved, deliberately or usually inadvertently, in multipublication. This includes, but is not limited to, the following: technical writer, copy writer, designers, product manager (or whomever writes price lists), translator(s), software developers, user experience designers, and so on.

For example, the person who writes the online help for a product may not be the same person who writes the printed documentation.

All types of information might be multipublished, as we have discussed earlier: specifications, operating procedures, prices, features, options, part numbers, maintenance procedures, graphics, and so on.

There are many places where product information might be multipublished.

Intra-Document Multipublishing

Information might be multipublished within the same content piece (intra-document multipublishing). This occurs, for example, when there are callouts in a graphic which are referenced in text, when headings are referenced from one chapter to another, and when parts lists and procedures both reference the same part. There are many other examples, however this shows a small variety of the types of information that might appear in more than one place in a content piece. There is no defense for including more than one specifications chart, or the equivalent, in a single content piece -- that is simply bad, dangerous technical writing and should never be done.

Inter-Document Multipublishing

Information may also be multipublished in different content pieces (inter-document multipublishing). Any product content piece may contain information multipublished in another content piece, including: user's guide, sales sheet, maintenance guide, specification sheet, parts list, sales catalog, and so on.

There are many reasons why information might be multipublished.

Sometimes information is published in more than one place in product content pieces because it was seen as beneficial to the customer. An example is when information is published in both a user's guide and a maintenance guide so that the customer does not need to look in two different books to find a piece of information. Sometimes, information MUST be multipublished within the same content piece. For example, callouts on graphics indicating part numbers or references to titles and figure numbers in other parts of the content piece.

Sometimes information is multipublished by accident. This happens especially in cases where many people are responsible for creation of product content pieces. For example, the technical writer did not know that the ad writer also used this information in an advertisement but used different values for the speed or battery life of the product.

Information may be multipublished simply out of habit: information has always been published in multiple places in this company's content pieces, so this process simply continues without questioning the direct (development/maintenance/update) and indirect (customer loyalty and confidence) costs. This is the most common type of multipublishing that I have run into in my career.

• During initial content creation.
• Before a new product is released: for example, sales sheets may be developed to pre-sell a product that is still in development, consequently they may contain pre-market information that ends up not making it into the final product or specifications (speed or battery life, for example) that turn out to be incorrect when the final product testing is complete.
• After a product is released: some documents may be written to supplement the existing documentation. For example, a quick-reference card might be developed after the regular user’s guide has been released or release notes might be developed indicating known bugs in software or known specification/performance differences (speed, battery life) from the advertised and documented product.

Although multipublication is beneficial in some ways for the customers, it must only be done by a project team with full knowledge of the extreme cost and coordination consequences. Also, it is imperative that all content creators are on board with the process and strictly follow the product and deliverable specification sheets and lexicons to ensure accuracy when multipublishing is done deliberately for different audiences or purposes (packaging text and documentation text, for example).

In product/process documentation, a rapidly changing type of content, the benefits of remaining flexible by minimizing multipublishing are significant and should be considered seriously. A product documentation project manager should calculate the benefits and the risks before allowing multipublication to occur in order to maintain optimal time-to-press or development time for their various types of content pieces.

Information about the author, a list of her complete works on HubPages, and a means of contacting her are available over on ==>Laura Schneider's profile page. But wait--don't go there yet! Please continue scrolling down to leave ratings and any comments you have about this article so that it can be improved to best meet your needs. Thank you!

_{All text, photos, videos, and graphics in this document are Copyright © 2013 Laura D. Schneider unless indicated otherwise or unless in the public domain. All rights reserved. All trademarks and service marks are the property of their respective owners.}