By Marina Sedmak, Kathleen Ruggeri, Robin Boldt, Sabrina Dennis, and Julianne Forsythe
Purpose: In complex content ecosystems, a consumable, visual view of the content landscape is necessary to describe a strategy for future content development. This article explains our content landscape, the rationale behind the development of a new visual method to represent that landscape, and the resulting analysis to support an overall content strategy.
Method: We present a technique that we used to analyze our complex content ecosystem of technical content and our approach to develop a consistent content strategy across documentation sets for diverse, yet interrelated products. We analyzed approaches that describe content strategy tools and processes for websites and for content reuse at the topic level, but found those lacking in support for complex technical content. Using that background, we designed our own tool and processes to support content analysis and strategy at the publication level. We developed the concept of a deliverable map, a visual representation of our content landscape by product category. The deliverable map became a highly effective tool in our efforts to define, communicate, and sustain our content strategy.
Results: Multiple deliverable maps show existing content and relationships, and provide opportunities for different levels of analysis and stakeholder engagement. This analysis supports development and maintenance of a content strategy that meets business goals and that drives content across multiple outputs. The deliverable maps communicate current state, show the evolution of deliverables, identify content issues, and guide future planning.
Conclusion: While the content in a content strategy initiative is typically thought of as small topics or webpages, it can be traditional publications also, such as technical manuals. Established content strategy practices can be adapted and successfully applied to content at all levels of granularity to meet the unique requirements of the organization. Spreadsheets are often the primary tool for documenting current-state content and planning future strategy. However, replacing spreadsheets with visual maps can be a more effective approach for complex, interrelated content landscapes. The interactive map becomes an invaluable tool to help create, communicate, and sustain a cohesive content strategy.
Keywords: content strategy, deliverable map, publication landscape, content inventory
- Presents a deliverable map as a visual method to represent a complex content ecosystem and high-level content strategy.
- Summarizes different levels of analysis that are based on the data that is captured in a deliverable map and the resulting relationships.
- Discusses how the analysis of a deliverable map supports the overall content strategy.
Rockwell Automation1 (NYSE: ROK, https://www.rockwellautomation.com) is the world’s largest company dedicated to industrial automation and information. Rockwell Automation comprises multiple business units that make nearly 400,000 unique products, both hardware and software, and mobile applications. Our control systems and components at Rockwell Automation are used in a broad range of applications, including automotive assembly lines, theme parks, breweries, pharmaceutical manufacturers, water treatment plants—virtually anywhere products are being manufactured and processes are being controlled. Along with maximizing productivity, our products and solutions help ensure the safety of people and processes in production environments. Our product and content ecosystems are broad and deep, and both need to endure for a long time. Customers rely on our products to be actively supported for decades to help them manage complex and high-volume production processes around the world, even while we develop new and exciting technologies.
To support customer needs effectively, technical communication management recognized a need to drive a more consistent content strategy across the entire product portfolio. Best practices dictate that planning for future content strategy begins with an understanding of existing content. Therefore, management challenged a small team of information architects within the department to develop a comprehensive view of the current state of the content landscape as the first step toward a future, unified content strategy. This effort resulted in the development of deliverable maps that visualize a complex content ecosystem. These deliverable maps are now integral to our progress toward a sustainable content strategy across our complex and expanding product portfolio.
Although some of our technical content is published to our website or as online help, most is published as long-form publications, PDF files, with over 12,000 actively managed publications. Information developers produce an average of 20,000 pages of new and updated technical content per year. This content is complex and covers user tasks ranging from initial product selection and system design to installation, operation, and maintenance of automation systems. The information development teams responsible for this content report to multiple managers and are dispersed across eight different locations.
Several years ago, faced with managing content for an ever-growing product portfolio, Rockwell Automation established the role of information architect within the Technical Communication department—a role that is not typically found within documentation teams that produce PDF, book-based content. It was clear that technical communication managers were juggling too many disparate content projects to effectively create and manage consistent content strategy across the entire product portfolio.
In Information Architecture: For the Web and Beyond, Rosenfeld, Morville, and Arango offer this definition of information architecture: “The art and science of shaping information products and experiences to support usability, findability, and understanding” (Rosenfeld, Morville, & Arango, 2015). Although usually thought of in the context of Web content, Rockwell Automation applied the practice of information architecture to content across our technical documentation landscape. However, even with the support of the information architects, the sheer volume of content remained a challenge.
Because simple products need only a few pages of content, whereas complex products require hundreds of pages of content in multiple publications, technical communication managers struggled with how to explain the depth, coverage, and evolution of our content across the product portfolio. They wanted an easily consumable view of our content landscape.
And because our many products are designed to work together, a significant amount of technical content is meant to intersect; but that content can also overlap. When the same content is created for multiple deliverables by multiples authors, it can result in conflicting user experiences. When the same content is rewritten, variations invariably creep in and cause confusion for users (Rockley & Cooper, 2012). Minimizing content repetition and achieving consistency across the product portfolio was a challenge.
And because of the longevity (20–30 years) and continuous development of Rockwell Automation products, the content is subject to significant changes. Without sufficient metadata to describe this evolution in our publication management repository, we lose historical context. For example, product evolution may drive changes, such as separating or combining content in novel ways; it is impossible to deconstruct those changes years later when a publication needs to be updated by a different information developer. This knowledge has always been tribal and, therefore, dangerously easy to lose.
Project Goals and Objectives
Understanding all aspects of current-state content is central to defining a content strategy for the future. It’s important to know how much content there is, what it is used for, and if it supports user goals (Casey, 2015). A current-state inventory and content audit identifies existing content and content relationships (Casey, 2015), provides the baseline to help identify issues for further analysis (Abel & Bailie, 2014), and provides the foundation for an actionable content strategy (Halvorson, 2009). For our content, we needed an effective visualization to show not only the publications but, more importantly, their relationships to each other. This visual approach would ultimately provide a simpler and more consistent way for information architects and technical communication managers to analyze our content and extend our content strategy.
To present the current-state content landscape, the information architects focused on a highly visual approach: scannable, digestible, and easy to execute following a consistent pattern. The solution had to support these objectives:
- Consistency in content types, breadth, depth, and treatment across all products and teams
- The ability to communicate strategy within our distributed team and to business stakeholders
- Maintenance of a current view of the entire content ecosystem for hundreds of product families and thousands of publications with histories spanning decades
Content strategy as a practice is relatively new and continues to evolve. Many of the available resources focus on Web content strategy and management. For the Web, content strategy typically addresses marketing content and brand messaging, with editorial calendars for content such as Web updates, social media, and blog posts. From the technical communication perspective, content strategy typically addresses planning for reuse of content chunks or topics across relatively homogenous content sets. As the information architects searched for guidance and best practices, nothing exactly matched the project goal: Create a highly visual representation of our extensive current-state PDF content landscape that could be leveraged to capture, inform, and extend our content strategy going forward. As a result, our implementation is unique, but our methodology is based on the basic principles of defining, building, analyzing, and extending the content strategy (Figure 1).
Most important in the process was defining the scope of products and publications, as well as the data about those publications that was important to capture. Then, we conducted the content inventory, built the solution, and validated both the information and the format before analyzing the results to extend the content strategy. Along the way, we were careful to consider the needs of all stakeholders.
To meet the project requirements, the information architects created the concept of a deliverable map to capture the content and strategy at the product category level (Figure 2). A deliverable map records publications and their relationships to each other, a brief history of changes, and attributes relevant to our content.
Although the deliverable maps were created primarily for the information architects to visualize and maintain consistent and coherent strategies, the deliverable maps were also expected to be valuable tools for the technical communication managers to assist with project planning.
Define the Solution
To plan and build out the deliverable maps, the information architects had to determine which products and related publications were in scope, decide what attributes related to the products and content were most valuable, and develop a visual format.
A website is often the starting point for a content strategy project. The parent site, content sections within the site, and pages within each section can help define the scope of the project (Halvorson, 2009). Content types, such as PDFs and videos, are recorded in the framework of the website (Halvorson, 2009). With our focus on PDF publications, we needed an alternate organizing structure for our content to clearly define what was to be in-scope. We looked at these factors:
- Volume and complexity of existing content
- Sheer number of products and the interactivity between them
- Longevity of our content
- Geographically dispersed content ownership
The Rockwell Automation product taxonomy was a logical starting point for scoping the content project (Figure 3). This taxonomy is robust, well-tested, and carefully maintained, providing a reliable framework for the deliverable maps.
The taxonomy divides the product portfolio into 19 high-level product categories, ranging from relatively simple components, such as push buttons or relays, to highly complex programmable automation controllers, to software products. Within these high-level product categories, there are hundreds of different product families. The Technical Communication department creates technical content for most of these products but doesn’t own the content for all of the product families due to the global nature of our company. To keep the scope more manageable, the information architects focused on the content for the products that are developed and maintained in North American campuses. Products documented by other technical writing departments, as well as marketing content for all products were deemed out of scope.
Reviewing the product lifecycle stage proved to be another important scoping technique. Focusing only on active and emerging product families concentrated our efforts on the most current content. Content for mature or discontinued product families is stable and unlikely to require revisions or further analysis.
Like most large companies with broad product offerings, Rockwell Automation uses multiple technical publication types. These include familiar types, such as Selection Guide, Installation Instructions, User Manual, and specialized publication types, like System Design Guides, that are used less frequently. Each publication type has a content model and is designed for different content, purposes, and audiences. Not every product uses the same publication types, so the scope of the deliverable maps included which publication types are used by which products and what purpose (user task) they address.
Even though some of our publications are translated into as many as 17 languages, limiting the scope to the source English content would keep maintenance manageable. However, as we evaluated publications, we realized that there was valuable history on translations that we included wherever practical. For example, some of our installation publications are multi-lingual—English plus additional languages in one publication. Identifying that a publication is multilingual is important because any revision to the publication requires planning for the translations, as well as the English content. In addition, regulatory concerns sometimes require publications in a particular language in order to certify a product for sale in countries outside of North America. By noting the reason for a specific translation, we capture a unique requirement that impacts specific product families.
Decide What Information to Capture
After deciding on the products and content in scope, the information architects determined which attributes were pertinent. We researched examples of Web content inventories that recorded attributes such as Web URL, references/links to the content, usage (Web traffic), content structure, and search engine optimization (SEO) data (Casey, 2015). We also researched topic-level inventories for content reuse that mapped where content elements are used—for example, manual, website, press release, and brochure (Rockley & Cooper, 2012). Additional research showed variations of these approaches, but nothing that would scale up to the volume and depth of our content landscape. Our project required that we define a unique set of attributes to help us understand our content ecosystem at a publication level.
The information architects defined attributes relevant and common to a comprehensive content inventory, such as ownership, history, status, and content purpose (Casey, 2015). Multiple attributes related to ownership identify areas of responsibility for content development. These included information architect (owns the content strategy), technical communication manager (manages the resources), and information developer (creates and maintains the content). The original attribute set included engineering resources (product development) and manufacturing resources (manufacturing facilities), but these attributes are difficult to maintain. Engineering departments reorganize and change product focus as companies grow. Manufacturing facilities that are associated with specific products also change over time as products mature. Capturing and maintaining engineering and manufacturing resources was time-consuming and proved irrelevant to our content strategy, so those attributes were removed.
To record the history of how publications have evolved, we included a Significant Event attribute, to capture events such as changes to publication types or content reuse, and the rationale behind those changes. The deliverable maps provided a way to record these changes that affect how customers access and use technical content, which would not otherwise be documented.
Attributes related to content status included:
- Publication Status (e.g., “In Progress”)
- Out of Scope (e.g., to identify product families that were nearing discontinuation and were not mapped)
- Open Issues (e.g., recommended changes for future content development)
Other attributes were relevant to the type of content within the publication or content purpose:
- In the Box (e.g., to identify a publication that ships in the box with product)
- Specialized Content (e.g., publications that require certification review before release)
- Shared Publications (e.g., a Selection Guide that covers multiple product families and would require atypical resources when being updated)
With the scope and attributes defined, the next step was to develop a format. For simpler projects, a structured spreadsheet is sufficient to capture the pertinent details about current-state content (Rosenfeld, Morville, & Arango, 2015). In fact, a Web search on content inventory templates shows many results that implement spreadsheets. Our work started with a spreadsheet, but showing relationships in a flat spreadsheet became impractical. Even with sorting, filtering, and using pivot tables, the spreadsheet wasn’t an ideal vehicle to visualize publications and the complex relationships that exist in our technical content.
To better show relationships, the information architects considered the concept of a mind map. According to Hopper (as cited in “Mind Map”), “A mind map is a diagram used to organize information visually. A mind map is hierarchical and shows relationships among pieces of the whole.” Our team had used mind maps to visually organize and structure information for other projects, so this was a logical approach to consider.
While mind maps are generally associated with brainstorming or organizing ideas, this approach was customized to capture existing content and tag content with descriptive attributes to show content relationships. We used commercially available mind-mapping software2 to build interactive maps. The mind map software also provided styles, tags, and icons that we customized and applied to the publications in each map to visually represent attributes and content relationships. The mind map format offered an information-rich view of our current-state content that could be queried and filtered to provide insights that guide content strategy decisions.
Build the Deliverable Maps
Once the format was defined, the next step was to decide how to organize the large set of diverse products in the deliverable maps. Creating one massive map was not feasible, nor very functional, so the information architects again used the Rockwell Automation product taxonomy as an organizing tool. Each product category in the taxonomy represents a distinct type of product—for example, push buttons or motors or automation controllers—with unique content requirements and publication landscapes. Within each product category are multiple product families that share similar content and publications.
Creating a map for each category of the product taxonomy was the right level of granularity to visualize content relationships across multiple similar product families. Although each category roughly corresponds to one deliverable map, the breadth and depth of some product categories required multiple deliverable maps to keep the content manageable. This granularity supports content analysis on a manageable scale and provides a structure that stakeholders would be able to absorb intuitively. Based on this analysis, we identified the need for 35 individual deliverable maps.
Create the Template
The work to create the deliverable maps was divided among several information architects. To improve consistency in treatment by different architects across so many product categories, we created a template (Figure 4). The template provided a hierarchical structure, identified how and where to add publications, and supplied pre-defined, formatted attribute tags, icons, and styles to be used in a deliverable map. A job aid provided detailed guidance on how to use the template, what information to capture, and how to represent content relationships.
Adhering to the template and job aid produced deliverable maps that were cohesive and provided a consistent level of detail. As the information architects worked through the maps, underlying product diversity and complexity often resulted in unique attributes that were added to the template during the course of the project (Figure 5). The template also helped surface content patterns that were consistent across product families, uncover inconsistencies that could cause findability issues, and identify product families with unique content requirements.
Conduct the Content Inventory
The core of a deliverable map is the current publication landscape for the associated product category. Information compiled from various sources enabled the architects to construct a comprehensive picture of our content. These sources included:
- Reports from the publication management system to identify active publications and ownership of that technical content.
- Department project lists to identify new and revised publication projects.
- Metadata from the above systems to identify the attributes for individual publications.
- Interviews with information developers to track down missing or conflicting information.
As is typical with content inventory projects, this was a time-consuming process that took about six months to complete. Content inventories in Web-based projects can benefit from using a site crawler to import the site structure and URLs to automate part of the process (Casey, 2015). We benefited from the reports and metadata from our publication management system and project list that automated the task of identifying in-scope publications. But most of the work to categorize the publications, associate them with the product families, add attributes, and build content relationships was manual.
Validate the Approach
Identifying the right stakeholders, getting them aligned with the project, and keeping them informed and engaged is crucial (Casey, 2015). Casey defines stakeholders as “anyone who can affect or is affected by your project” (Casey, 2015, p. 28). We identified two key stakeholder groups for the project: technical communication managers and information developers.
The technical communication managers were involved in the initiation of the project, setting the vision and goals for the project; we needed to make sure that they were aligned with our approach and that the deliverable map format met their expectations. The information developers would be essential in validating the completeness and accuracy of the information in each map, and an important resource for ongoing maintenance of the maps.
With these stakeholders in mind, the information architects shared a few initial drafts with them to validate the scope and direction of the deliverable maps before moving to complete all 35 projected maps.
This validation process helped foster a sense of familiarity, acceptance, and ownership of the deliverable maps and provided valuable feedback toward their development and use.
- Technical communication managers validated that the deliverable maps had the right level of information and that the deliverable maps would be useful tools for their planning and communication needs.
- Information developers validated the accuracy of data in the deliverable maps. The deliverable maps are actually their “story,” where their efforts in producing great content are documented. The information developers also provided historical “tribal knowledge” for how publications arrived at the current state. These project-related perspectives were embedded directly in the deliverable maps.
With management support, the information architects continued to work with information developers to validate each map throughout the development process.
Launch the Deliverable Maps
Upon completion of the deliverable maps, we posted them on a department SharePoint site. To aid in usability, the information architects created a job aid with examples on how to query and filter the data to support content analysis. The job aid included use cases for how technical communication managers and information developers could best use the deliverable maps.
The information architects also hosted hands-on demonstrations for the technical communication managers to show how the deliverable maps could answer common questions, such as:
- What are all current technical publications for a product family?
- Which publications are shared across product families?
- Does this product family have a selection guide?
- Are all of the publications for a product family following a consistent pattern to make them predictable for the customer?
- Which publications have issues that could impact the scope of a revision or the findability of information?
- Which publication types are required for a new product family?
Tags, icons, and pre-defined queries were built into the deliverable maps to simplify their use.
Sustain the Process
The deliverable maps were not meant to represent a single snapshot in time. Rather, they are living, current-state artifacts that must be maintained to continue to fulfill their function. The high volume of technical content that supports Rockwell Automation products meant that the effort to keep the deliverable maps current must not become a burden on the Technical Communication department. The result was a process of quarterly updates to the deliverable maps based on active project list data, publication release reports from our publication management system, brief interviews with information developers, and early participation on product development teams. This process identifies new and obsolete publications with minimal disruptions to technical communication projects in progress.
Frequent consultation of the deliverable maps during project planning enables us to organically identify most product developments that result in updates to the deliverable maps or the potential creation of new maps for new product categories.
Analyze Deliverable Maps to Impact the Content Strategy
Content strategy is often described in the context of Web content and how it is structured and stored in a content management system. In her blog post, “What is Content Strategy? Connecting the Dots Between Disciplines,” Halvorson (2017) offers this macro definition: “Content strategy is an integrated set of user-centered, goal-driven choices about content throughout its lifecycle” (para. 10). She contends that “how you define content strategy for your organization depends … on what you’re trying to accomplish.” On the most basic level, content strategy is an integrated approach to planning and delivering content (Halvorson, 2017).
Our Technical Communication organization has a robust publication management system and metadata strategy in place for PDF publications. Our content strategy does not address managing content from that perspective. Our focus on content strategy is about the analysis, planning, and delivery of content to support customer information needs. The deliverable map represents our content strategy; the deliverable map helps us analyze our content to make “user-centered, goal-driven choices” (Halvorson, 2017) about what we create and deliver.
The deliverable map, as a visual representation of existing publications and content relationships, provides opportunities for multiple levels of analysis. Regular review of the deliverable maps helps develop and maintain a consistent content strategy that meets business goals and that manages content across multiple publications. The visual format is easily consumable by information developers, technical communication managers, and other product stakeholders. The deliverable maps communicate current state, show the evolution of publications, identify inconsistent patterns in content or deliverables, and guide future planning. All or part of a deliverable map can be shared with the large set of company stakeholders to support recommendations for creating new content or revising existing content.
Content can also be compared horizontally across the product families represented in a deliverable map to help verify that the right content lives in the right publications. Defining the expected or required content against the current state helps identify content differences, redundant content, and deviations from typical content types.
The deliverable maps make it easier to analyze publications for consistency across the same publication types, to maximize content reuse, and to minimize unnecessary duplication. The deliverable maps show where opportunities for improvement exist. Taking advantage of these opportunities results in more consistency, which, in turn, helps customers find the quality information that they need more quickly. The customer experience becomes easier and more predictable as customers research, select, and use our wide array of products. Following are examples of how we review and analyze the deliverable maps to evaluate alignment with content strategy.
Identify Content Differences
Publications in our content landscape support high-level tasks and span the full user information lifecycle. Tasks include:
- Product selection and system design
- Installation and configuration
- Operation and maintenance
- Product replacement
The information architects identified a core set of publication types with well-defined content models to support these user tasks. These user tasks are the same across our product portfolio, in spite of the diversity of the products. The standard set of core publications may vary between categories, but is typically consistent across product families within a category. In a deliverable map, publications are grouped by these high-level user tasks. Each product family in the map is expected to have the same core set of publications to support these tasks. An information architect or manager can scan all product families in a map to validate that each has the correct set of publications (Figure 6). The visual nature of the deliverable map makes content issues readily apparent. A deeper analysis of the map provides additional information that can be used to determine what is needed to bring the content in line with current strategy. Decisions are captured and maintained in the map as part of the content strategy.
Plan for Shared Content Dependencies
An important attribute in the content inventory is the identification of publications that are shared by multiple products, either in the same product family or across multiple product families. The deliverable maps identify shared publications by using a particular style so they are visually distinct from non-shared publications. Changes or additions to content in a shared publication have to account for all of the associated product families, which increases the complexity of projects involving these publications.
Figure 7 shows a portion of a deliverable map for the Automation Controllers product category. Within this category, there are three Rockwell Automation product families: Large, Small, and Micro Controllers. Each product family is owned by an information developer in a different geographic location. Mapping the publications in this content ecosystem reveals that one of the publications, Automation Controllers Selection Guide, is a shared publication. It contains content for all three of the product families to help customers compare and evaluate products to select the best controller for their application. The blue oval format in the deliverable map visually indicates a shared publication. The technical communication manager can review the deliverable map, see that this publication is impacted by product developments in both the Large and Small Controllers product families, and schedule the changes to be made within the same publication update cycle. Content dependencies become transparent when exposed visually in the deliverable map.
Review Significant Events
Technical communication managers make decisions every time they plan content for product developments: create new publications, update existing publications, and sometimes move existing content to different publications. These decisions are based on product-specific requirements. Some of these decisions can also affect how customers access and use technical content. Recording these decisions as Significant Events helps maintain that knowledge and the reasons behind the decisions.
The purpose of Significant Events is to provide an explanation of how publications evolve over time, especially for more complicated publication sets, which include a variety of publications.
Figure 8 illustrates a Significant Event that changes the original content strategy to improve the customer experience. This example documents how content from several user manuals that have similar content about a product family or related families was combined into one common user manual. This improves the customer experience by placing related content in one location; the customer no longer has to search multiple user manuals.
Recording publication evolution preserves historical information and helps explain changes in the publication landscape for a product category. Significant events can be driven by product enhancements. For example, if a product is modified to allow repairs in the field, the publication set might expand to include a service manual. Other types of significant events could be the result of internal business factors, such as a shift in ownership of a publication from one writing group to another.
Over time, strategy decisions can be based on past Significant Events that positively impact findability, usability, or maintainability. Conversely, the history of Significant Events can minimize the likelihood that we would repeat past decisions that negatively impacted our internal processes or the experiences our customers have with our content.
Review Open Issues
An analysis of the current state in a deliverable map can identify content issues that should be addressed. These issues could be misalignment with the content strategy, as well as missing, outdated, or redundant content. Publications with issues are marked with an Open Issue tag and highlighted with a color in the deliverable map. A description of each issue is also embedded in the deliverable map in a Notes section. To assist with project planning, the technical communication manager can filter a deliverable map to display any publication with an open issue. Resources can then be allocated appropriately. Critical issues can be addressed immediately, while others may be scheduled as part of a planned update cycle. Documenting known issues in this way helps bring and keep content in alignment with the strategy.
As an example, in the Automation Controllers deliverable map shown in Figure 9, the large and small controller products each have a single User Manual that covers all of the controller models in that family. In contrast, the micro controllers still have a separate User Manual for each model. The open issue tag and note indicate that the micro controller publications should be analyzed at the next revision to make them more aligned with the current content strategy.
Extend the Content Strategy
Information architects use the deliverable maps with marketing and product stakeholders to explain the content landscape for their products. This visual representation of their publications, which can range from a few to dozens, helps focus discussions that have future content strategy implications, such as how and where to document new products or whether the information developer should restructure existing publications to incorporate new technologies. It’s beneficial when stakeholders can visualize for themselves the impact of decisions on content strategy.
The deliverable maps help surface common themes across multiple, complex publication sets for a wide variety of products. Our analysis of the deliverable maps and knowledge of customer requirements leads to more complete and informed content strategies.
Information architects created deliverable maps to help technical communication managers and information developers understand and manage complex content strategies and interrelationships. These deliverable maps are a complex tool for large ecosystems of diverse technical content, and are not well suited to capturing content strategy for homogenous or small-scale content. To provide a valuable return on investment, they are best applied in scenarios such as these:
- Large volume of content—hundreds or thousands of artifacts
- Heterogeneous content without obvious or simplistic patterns of technical content
- No existing content management tool or process that describes the content landscape using built-in tools
- Significant longevity of content due to the nature of the subject matter (e.g., new content does not simply replace old content)
Figure 10 shows a portion of a larger deliverable map for a complex product category called Low Voltage Drives. The deliverable map shows various details about the publications for these products, documents strategy decisions, and displays this information visually. The interactive deliverable map can be filtered to show only certain types of content and relationships across multiple product families. Deliverable maps for similar products, such as Medium Voltage Drives, can also be compared for strategic consistency.
Another important touch point for the success of the content strategy is how customer and stakeholder feedback can be evaluated against the content ecosystem in a deliverable map. Content feedback comes from technical support calls, trade show interactions, and publication problem reports. The feedback is reviewed based on the details in the deliverable map and documented to guide future content development to improve publications.
As Rockwell Automation products become more intelligent, providing more data about process, quality, throughput, and device health directly from the plant floor, our content continues to evolve and grow in complexity and quantity. Technical content must support our customers in their journey to achieve a Connected Enterprise—the convergence of plant-level and enterprise networks that securely connects people, processes, and technologies. This means that technical content must be consistently structured and easily findable in our large and ever-growing content ecosystem, and this only happens with a visible and clear content strategy.
The deliverable maps are our primary tool to support a consistent and predictable information experience for our customers. They make it much more likely that our content can answer the important questions customers have at all stages of their interactions with us. This visual representation of our complex content ecosystem gives all stakeholders a concrete way to experience and unify around the content strategy.
In our environment, the deliverable maps:
- Let information architects effectively plan future publication development and organize the right content in the right publications
- Support technical communication managers as they plan for the execution of a high volume of critical content with the confidence that the information developers are creating content consistently across product families
- Support information developers in their goals of creating accurate and high-quality content for our customers
Ultimately, product deliverable maps let our customers be more successful in finding and using our technical content as they work to accomplish their own critical goals.
Our research has shown that managing complex and unique content ecosystems requires innovative approaches to information architecture that can scale to the volume and depth of current content. Over time, as we explore new approaches to creating and managing content outside traditional long-form PDFs, deliverable maps will form the foundation for the discovery work required to evolve. We are much better prepared for our future with such a robust set of living, knowledge artifacts that can grow and adapt as we do.
- Headquartered in Milwaukee, WI, Rockwell Automation employs approximately 23,000 people, serving customers in more than 80 countries.
- A Web search reveals many free, online, and for-purchase mind mapping tools, ranging in sophistication and functionality. We used Mindjet MindManager software for our project.
Abel, S., & Bailie, R. A. (2014). The language of content strategy. Laguna Hills, CA: XML Press.
Casey, M. (2015). The content strategy toolkit: Methods, guidelines, and templates for getting content right. Berkeley, CA: New Riders.
Halvorson, K. (2009). Content strategy for the Web. Berkeley, CA: New Riders.
Halvorson, K. (2017, October 26). What is content strategy? Connecting the dots between disciplines. Retrieved from: https://www.braintraffic.com/blog/what-is-content-strategy
Mind Map. (n.d.). Retrieved from https://en.wikipedia.org/wiki/Mind_map
Rockley, A., & Cooper, C. (2012). Managing enterprise content: A unified content strategy. Berkeley, CA: New Riders.
Rosenfeld, L., & Morville, P. (1998). Information architecture for the World Wide Web. Sebastopol, CA: O’Reilly Media.
About the Authors
Marina Sedmak is Senior Manager of Information Development and Publishing and manages a diverse team of information developers and information architects at Rockwell Automation. She has over 30 years of experience in technical documentation and translation management at Rockwell Automation and predecessor companies. Currently, her team is responsible for supporting technical documentation requirements for nearly 400,000 diverse automation products. She is available at email@example.com.
Kathleen Ruggeri is Manager of Information Architecture and Content Quality. With over 30 years in Technical and Marketing Communications at Rockwell Automation, Kathleen currently manages the Information Architects responsible for business-level technical content strategies and product-level documentation planning. Kathleen is also the program manager for the Content Quality initiative, focusing on automated content editing and terminology management. She is available at firstname.lastname@example.org.
Robin Boldt is an Information Architect with Rockwell Automation. She has been in the Technical Communication field for over 30 years. At Rockwell Automation, she has written online and print content for both software and hardware products. Currently, she is responsible for developing a visual, comprehensive content strategy for a complex content ecosystem and sharing that strategy with multiple stakeholders to drive consistent content. She is available at email@example.com.
Sabrina Dennis is an Information Architect with Rockwell Automation. Her focus is on developing comprehensive content strategies for functional safety, drives, and motion products as well as product-level documentation planning. She also manages a Functional Safety Community of Practice where information developers at Rockwell Automation can share their knowledge and experience in creating documentation for these products. She is available at firstname.lastname@example.org.
Julianne Forsythe is an Information Architect and has been part of the Technical Communications organization at Rockwell Automation for 20 years. Currently, she focuses on high-level information architecture, analysis, and design of content strategies for current and emerging content areas. Julianne’s experience also includes technical and marketing communications, Web content development, user research, and SharePoint development to support internal processes and tools. Her prior experience includes investor and employee communications. She is available at email@example.com.
Manuscript received 2 July 2018, revised 8 January 2019; accepted 19 January 2019.