Part 1: A Guide to Migrating to Structured Content

Everyone is telling you it’s time to migrate your technical documentation from its unstructured format in MS Word or PDF to a structured format to improve your ability to manage and scale it. Is it the right thing for your company? To come to a decision, you need to understand the difference between structured and unstructured content and the reasons that would make you want to migrate to a structured format. That’s what we’re doing in part one of this two-part series on how to make your content highly efficient.

Paligo recently hosted the webinar “Make Your Documentation Highly Efficient—Without Risk” to discuss the shift from unstructured to structured documentation. The webinar was packed with expert advice from Sarah O’Keefe, CEO and founder of Scriptorium, and Paligo Solutions Engineer and Information Architect Gershon Joseph.

Along with helping you understand the difference between unstructured and structured content, we’ll talk about how to determine if you’ll need a component content management system (CCMS) to help you move to a structured content model. We’ll wrap up part one with a set of steps to help you decide if you should migrate.

Let’s dive in (you can find Part Two here).

Every company creates unstructured content. If you use MS Word, Google Docs, or PDFs for your technical content, you have unstructured content. Unstructured content refers to information that lacks a required predefined, consistent format. It mixes formatting and style with the content and doesn’t follow predefined rules, making it more flexible and less constrained.

Examples of unstructured content are PDF and HTML versions of product user guides and administration guides built using Word, Adobe Indesign, and similar tools.

Sarah noted that unstructured content is not necessarily bad. Using unstructured content can work fine if your documentation team is small and you don’t have much documentation to create and manage. For example, a small content set that documents a single product with no variations and is published to one or two output formats would be fine to manage using an unstructured content model.

However, you will struggle with unstructured content as your requirements grow more complex. Sarah explained that as your requirements change, you have more content variance. So, for example, you manage documentation for a product with a light and premium version, adding an enterprise version. If that documentation also needs to be translated and delivered to multiple channels, things just become a lot more complex.

“Every time you add an output channel, a variant, a language, a localization, it becomes more difficult to manage that content in an unstructured environment. So the bottom line problem is that unstructured content doesn’t scale for the kinds of requirements that we have for most technical content these days.” – Sarah O’Keefe

More examples can help explain why unstructured content is a bad idea for most technical content.

• Personalizing content: You have an administration guide for your product that needs to be split in a version that supports beginners or basic administration tasks, and a version with more advanced features.
• Publishing content: To support your customers where they work, you publish your documentation to downloadable PDFs, a support portal or website, a knowledge base, and a chatbot.
• Product versions: SaaS vendors typically offer product versions, such as freemium, basic, professional, and enterprise, each providing different features and functionality.
• Translated content: Your product is available in multiple countries, so you need to translate your documentation into multiple languages. Also, your product has a slight naming difference in some countries.

In all of these examples, if you create your content in Word or Google Docs, you have to create multiple documents, one for each version you need. So you are creating a user guide for the professional, enterprise, and basic versions.

If those guides are available in English, French, and other languages, then you have a document for each translation.

If you are publishing the guide to multiple channels, you will have a PDF document, HTML web pages for the website, CHM files for in product help, and HTML files for the knowledge base.

Imagine the effort required to keep all these different versions in sync. Every time a new feature is updated or added to the basic version of your product, you have to go through every document version to make the change, then send every document for translation, and then create HTML and CHM files to update the other channels.

And we haven’t even talked about white labeling your product and associated documentation across customers, markets, or industries.

Managing technical documentation using unstructured content can significantly impact team productivity and content velocity. Your documentation team spends more time keeping existing content up to date than creating new content. And when they do have time to create new content, they have to create multiple versions. Plus, all those documents have to go through a separate review and approval workflow to ensure they are accurate and up to date before publication.

A structured content model is starting to sound pretty good, doesn’t it?

Managing documentation using a structured content model is a very different story. Structured content is information organized in a defined format or schema, allowing for easy categorization, retrieval, and analysis. It follows a specific set of rules that define the structure of the content, while style and formatting are completely separate.

Both Sarah and Gershon understand the value of a structured content model. But they first want you to decide if moving to one is worth the costs. Investments in technology (e.g., CCMS), content migration, and changing the way you work all need to be considered.

Sarah said you have to map out the benefits you will derive that make migrating worthwhile.

Let’s look at cost avoidance first.

“There’s an investment in migration. There’s an investment in changing the way that you work and all the rest of it. So the question you have to ask is, what benefits will I derive from this, and what makes it worthwhile? And the most obvious place that we always start is cost avoidance.” – Sarah O’Keefe

A structured content model means most of your content is single-sourced; you create one version of the content and reuse it for all your documentation needs. You can create multiple documents or publish them on multiple channels using a single version of the content. Sarah said you aren’t creating a paper-based layout and then trying to format that for HTML. Instead, you create your content once and then use automation to transform the output into multiple formats and languages.

Formatting is also a velocity issue. Sarah said technical content writers spend up to 50% or more of their time on formatting in an unstructured content environment. When you use a structured content model, you can publish your content faster because there’s only one version to review and approve and one version to publish in different formats. Need to make a change? Do it once, and all publications are automatically updated once that change is approved.

Translations also get cheaper because you translate your content before you format it. Sarah said to take a look at the breakdown in your translation invoice. There is project management, linguistics (the actual translation), and DTP (desktop publishing formatting). DTP is typically 30-50% of the total invoice. Take that DTP work away, and your translations just became much cheaper.

By following a structured content model, your content can also be used for multiple purposes. The marketing team can use the content on the brand website or in blogs, and the training team can use it to create lessons in a course. The product team can use the content in-product help, and the development team can use it in mobile apps.

Sarah pointed out that a structured content model prepares content for channels and use cases you may not even know about yet.

Trying to keep your technical content updated is an arduous process most of the time, but it’s even worse when you have to track and manage multiple copies of that content. Single-sourcing content using a structured content model means you only have to change the content once, and those changes are automatically reflected everywhere it’s used. This means your content is always accurate, no matter where it’s published. And it’s always consistent across channels, which is critical for ensuring a great customer experience.

If you are publishing your content to other platforms, like a knowledge base, a ticketing system, or a content delivery platform, it’s much easier to set up the integrations when you are working with a set of content that is consistently defined.

Structured content is also easier for large language models to ingest and understand for applications using generative AI.

The next question you might ask is, what kind of a component content management system do you need? And do you need one at all?

A component content management system (CCMS) is a CMS designed specifically to create and manage structured content. Unlike a traditional CMS, which manages web pages and blog content using predefined templates, a CCMS manages components, which are modular, reusable content chunks you can mix and match for different publications.

Do you need one to manage your structured content? Gershon said it depends. If you publish content to a small number of targets (channels) or have a limited number of variants, you might not need a CCMS.

“I know of one very large enterprise that does structured authoring without a CCMS. Now, they’re the exception. They’re not the rule. But usually, if you need additional things beyond just the things that structured authoring gives you. So, for example, you want workflows, you want review and approve, and you want the ability for casual contributors like subject matter experts to also submit content. And you want to automate your translation workflow as much as possible.” Gershon Joseph

If you have many channels and variants, a CCMS makes it much easier to structure content. It also allows you to set up workflows such as including reviews and approvals, enables subject matter experts to contribute to the content, integrates with translation management systems for automated translations, and integrates with training management systems and content delivery platforms.

Sarah agreed, saying you have to weigh the costs of purchasing a CCMS, the licenses you need, and the configuration and administration required against the cost of doing it manually. Think about the time, money, effort, and people required if you don’t have a CCMS. She said the bigger the workflow and more complex the requirements, the more you will need a CCMS. However, she has also seen smaller teams benefit from using a CCMS.

As your product becomes more complex, the number of variants start increasing, or you need to white label your content, a CCMS starts to make sense. A CCMS provides a lot of functionality that supports these needs, including taxonomy-based profiling, variables, versioning, branching, and merging.

Also, as Gershon points out, a CCMS enables you to create workflows for content assignment, review, and approval of content; it enables external parties like SMEs to create content or review and comment on content and provides reporting on the content status.

A CCMS also provides integrations with key systems, such as translation management systems, training management systems, support portals, content delivery platforms, and help desk systems.

Still not sure if migrating to structured content is the right choice? Let’s walk through this step by step to help you make the right decision.

The first thing you need to do is assess your current documentation process. Ask yourself and your team:
What challenges are you facing today?
Are you struggling with inconsistency? Slow publishing cycles? High translation costs?

Be specific and, if possible, quantify the impact of these problems. Refer to the translation invoice example above.

Next, conduct a preliminary content audit to understand the types of content your team is creating and managing. List the channels where that content is published and the format for each channel. Note the versions of each content type you have to manage, including variants for the end user, language, market, etc. Your list doesn’t need to be exhaustive, but it needs to be enough to understand the scale and scope of the content you work with.

Don’t forget to talk to your team. Talk to your writers, editors, and other stakeholders involved in the content creation and publishing process. Gather their feedback on the current system and their pain points. What are their biggest frustrations?

Once you’ve analyzed the current state, think about your future content needs.

• Is your company planning to expand into new markets?
• Do you need to support additional languages?
• Are you planning to introduce new products or significant changes to existing products?
• Will you be introducing new publication channels?

Think about how your current process will support these changes. What challenges do you expect? Will you need more resources, time, and money to support these?

Now, define some measurable goals you hope to achieve by migrating to a structured content model. Identify goals such as:

• Reduce translation costs
• Speed up the SME review process
• Reduce the amount of content created
• Improve publishing speed
• Increase the scalability of your content.

Having concrete goals will help justify the investment in migrating to structured content.

You’ve identified your existing state and future goals. Now, let’s dig into your content a little more. Gershon said to identify the complexity of your technical documentation. How many products does your company have? Are there variants, different configurations, or optional features? If it’s a subscription-based product, how many editions do you support?

How many different documentation types do you manage for each product? Each product variant? The greater the complexity, the more likely you are to benefit from structured content.

Go deep in your channel analysis. Outline all the channels where you publish your content. Identify the format of that content, if you need to provide variants, and what systems are integrated. Also, describe how the publishing process works and how it could be streamlined if you have structured content.

At this step, you also need to evaluate your team. How big is your documentation team? Are they spending most of their time updating content and unable to respond to new requests? How do they work with SMEs? Do they have complex workflows and approval processes?

Do you need a CCMS to help you migrate to structured content? Start with a preliminary evaluation to determine if you do. Then, if you decide you do, evaluate the options further.

It is important to remember that not all CCMS are the same. Map out your requirements and then look at factors such as features and functionality, integration capabilities, costs, and vendor support.

You don’t have to conduct an in-depth evaluation; just a preliminary overview. Create a spreadsheet and list the options with high-level information.

You’re now at the stepwhere you have to analyze the costs versus the benefits. Estimate the costs associated with migration, including:

• Software and licenses
• End-user and administrator training
• Professional services
• Time required for your team to migrate the content

Weigh the costs against the benefits of structured content, such as reduced translation and time to update or publish new content. Maybe you were requesting budget to hire additional resources, but by using structured content, you don’t need those additional resources. What are the costs associated with adding and updating content on different channels? Will that be reduced by using structured authoring and a CCMS?

Calculating the return on investment (ROI) based on your measurable goals might not be a perfect science, but you can understand it enough to make an informed decision and justify the investment to stakeholders. Try out Scriptorium’s Content Operations ROI Calculator to get an idea of the potential gains for your organization.

After reading through this article, you should have everything you need to make the right decision. Is moving to a structured content model the best choice for your business? Will you implement a CCMS to support the use of structured content?

If you decide to move forward, you’ll need to start the migration process, which includes a more in-depth content audit, content modeling, selection of tools and technologies for the migration process, and selecting a CCMS.

This sets the stage for Part 2 of this blog series, which will cover the actual migration process. Sarah and Gershon have great advice to help you migrate successfully.