Improving the quality of AI-driven technical content delivery

Did you know that many field engineers spend 30 to 50% of their time on finding the right instruction? Although there is no miracle solution that provides end users with fully contextualized instructions yet, AI-driven content delivery opens the door to a better user experience and higher efficiency in operating, troubleshooting, and repairing technical products.

In the mid-1990s, I discovered that no matter how much effort I put into creating readable, task-based instructions, my users would rather grab a phone and call the service desk than look for the right instruction in my beautifully designed and well-written user and service manuals. The reason was that it was quicker for my users to grab a phone and make a call than to find the right instruction – based on their context – in my manuals.

When I compare this situation from 30 years ago with how field engineers operate now, I can conclude that not much has changed in how we present technical instructions to end users. Over time, many paper-based manuals have been replaced by documentation portals and PDFs, but the process of finding the right instruction still involves a lot of going back and forth between troubleshooting content and repair instructions and asking for help from more senior colleagues. This has everything to do with the fact that many organizations still ask us to structure the information in linear documents as if we were still producing paper manuals, creating a gap between our technical documentation and the complexity of the physical world.
 

Meet the virtual co-engineer

So, how can we bridge this gap between our documentation and the physical world?

To investigate the possibilities and set a path to the future, I worked with a team of industrial designers and AI developers on a concept called ‘the virtual co-engineer’. Our objective was to provide field engineers with the best possible user experience, using a combination of customizable wearable hardware and AI to assist engineers in maintaining, troubleshooting, and repairing technical devices using the technical documentation as the source. To do so, we had user experience designers observe how field engineers do their work and deeply analyze their processes, needs, and challenges.

Then our product designers started designing dummy hardware to test how we could best support the engineers, while a software design team started the design process for human interaction models. This dummy setup was then tested with one single product, and – based on the outcome of the evaluation – a fully functional setup was created that could support users in a limited set of troubleshooting procedures for this product. In this setup, the user can use the camera and microphone to identify product versions and potential problems, ask questions about the documentation, get assistance in troubleshooting, and retrieve the right instructions and technical diagrams.

This setup was tested and worked well with one product – a drone developed for Wings for Aid – and a limited documentation set that was designed for AI-driven content delivery. In this approach, the field engineer remains in charge of deciding which action to take, while the virtual co-engineer acts as a co-worker who supports the engineer during all activities. While we proved the effectivity of the setup, we didn’t answer one important question: How can we apply this concept in a multi-product environment with customized products and many product variations without introducing risks in the troubleshooting, repair, and maintenance activities?

AI-enabled technical content delivery

In my view, three important aspects influence the impact of AI-enabled technical content delivery:

1. Content delivery & user experience: How to bring value to end users through AI
2. Content architecture: How to prepare content for non-linear, context-driven usage
3. Content authoring: How to use AI in our authoring processes to create well-written, complete, correct, and up-to-date content
    

Content delivery & user experience

AI-enabled content delivery is perhaps one of the most popular topics at any technical communication conference and in many social media feeds from technology vendors and service providers that focus on technical communication. The presentations, demonstrations, articles, and videos almost give us the impression that effectively using AI in content delivery is already a commodity. Unfortunately, this is far from the truth.

Based on my experience in the automotive, aerospace & defense, rail, energy, and industrial equipment industries, I estimate that roughly 50 to 60% of large industrial enterprises are actively transitioning from static content to modular, API-driven content delivery for their service documentation. For other domains, like marketing-related information and owner documentation, these numbers are different, as many enterprises prioritize client-facing documentation over non-client-facing documentation. Some companies have set the first steps and started with AI initiatives to support engineers. And even though interactive instructions are listed as a priority by many of these enterprises, only a very small proportion of them have moved to implementing AI in content delivery for troubleshooting, repair, and maintenance instructions. Most of these initiatives are still in the proof-of-concept phase, and of the ones in production, those that deliver measurable results are negligible.

And this brings us to the question: Why do most enterprises find it challenging to implement AI in content delivery?

While there is no single answer to this question, it is evident to me that the challenge lies less in the AI capabilities but more in the way the technical content is written, structured, and stored. For example, at one of our clients, the product configuration of each installation is different and requires a different set of repair instructions for each installation. If the AI cannot retrieve the right instruction based on content and identifiers, our solution would be useless. In another situation, engineers have to work in a very tight space. While lying on their backs to perform the work, there is no room to check the steps on a laptop or tablet. In this case, the content needs to be prepared to be presented on a very small display or to be spoken by the AI ​​through the engineer's headset. A multi-page instruction that is not tailored to this situation would not add any value here. As technical authors, we need to understand the circumstances under which our content is used and design it accordingly.

 To provide AI-enabled content delivery that truly delivers value to engineers, we need:

1. Clear instructions: understandable, well-written, and fitting smaller displays
2. Correct instructions: complete, accurate, and up-to-date
3. Consistent instructions: modular and compliant with relevant standards like S1000D, DITA, or any custom structured format
4. Relevant instructions: findable and belonging to the correct product variant and version.

There is no doubt that IT plays an important role in AI-driven content delivery, but ultimately it is we – technical authors – who determine success or failure.
 

Content architecture

Every technology vendor of Component Content Management and Common Source Database (S1000D) will refer to modular, structured content as the best enabler for AI-driven content delivery. It will provide us with the consistency and predictability we want in our instructions and with the meta data to more easily identify and retrieve the content.

Although these technology providers are right, the reality is that many enterprises have a scattered ecosystem of authoring tools and systems, where documentation is stored in multiple formats.

With the rise of Generative AI, many companies thought they could reduce the dependency of their content architecture by using Generative AI to generate instructions in real-time from non-structured content. While this approach could potentially provide reasonable results in simple, descriptive content based on well-structured content, the results for generating technical procedures and instructions from unstructured content were practically unusable for field engineers. The instructions provided by the AI were often not relevant, not trustworthy, and not understandable in the context of the work to be done.

So how do we handle situations where not all content is structured within one format and in one repository? I recommend following a two-track approach:

On the one hand, start standardizing the content architecture and move to one single system for modular, structured content. This will provide the highest reliability and best user experience in the long term. In parallel, deploy a solution that can aggregate documents stored in multiple systems and formats and use that to prepare a repository of semi-structured content modules. While the transition to structured content will take a long time and would typically cover newer products, the added aggregation layer will enable instant results and cover all products, and allow the integration of content from sources such as ticketing systems and SharePoint. For instance, we deployed a solution for an aerospace OEM that creates modular content out of PDFs, allowing clients to interact with the documentation through a chatbot. At tcworld conference, I also saw a demonstration of Fluid Topics, a commercial product that is designed as an aggregation layer with an MCP server to support Agentic AI integration.
 

Content authoring

As technical authors, we are experts in creating readable, task-based instructions that are well aligned with our target audience. Creating well-written, complete, correct, and up-to-date instructions is at the core of our work, and our work would – by definition – be ready for AI-driven content delivery once the content architecture is in place.

Within the technical authoring teams that I have been working with, I noticed three important challenges:

1. There is a lot of pressure on teams to speed up authoring and publishing timelines.
2. Working with subject matter experts is considered complex and time-consuming, often involving multiple revision rounds between initial intake and final draft.  
3. Updating documentation after product updates can take up to 80% of the available time, since even a small change in a part or procedure can have an impact on instructions for multiple products.

While enterprises still struggle with implementing AI in content delivery, there has been much progress in using AI in the authoring process. From my own experience, Agentic AI can be incredibly effective in supporting technical authors in handling these three challenges. Think of AI agents that help identify reusable content for new documentation projects, do an impact analysis upon receiving a product change, or verify the correctness of a procedure by simulating the activities from the procedure on a product’s digital twin. A good example with a huge impact on how we can work with subject matter experts is the AI agent we developed for one of our clients to transcribe an interview between a technical author and an SME and create a DITA-compliant instruction based on the conversation. While technically speaking a very simple solution, the business impact was that 2 weeks of going back and forth between author and SME was reduced to 1-2 hours of work, where the SME could instantly provide input on the first generated draft of the content.

Another example is the agent we developed for another client that identified all impacted data modules from an engineering change and guided the authors through the execution of the changes.

What all these successful cases have in common is that AI is not used as a replacement for a technical author but as a co-worker.
 

How I learned to stop worrying and love AI

As technical authors, we are on the verge of a new era in which our work will become more important than ever before. If we compare the use of AI in content delivery with an iceberg, then what we do is the part that is hidden under the water: modular, well-written content. With the introduction of new AI-driven concepts for service documentation, like the virtual co-engineer, the need for content that is optimized for AI-driven delivery will grow.

AI concepts like the virtual co-engineer will take time to develop and mature before engineers will be able to fully trust them. This gives us time to prepare ourselves for these new ways of content delivery while learning how to best use AI in our authoring, translation, and publishing processes. Where many of us might still fear that machine authoring will be replacing our work, it has become clear that the role of AI will be more in supporting authors than in replacing them.

By reducing time spent on activities that bring little value, authors can focus on what is most important: creating usable technical content that can be published in the operating and service manuals and is ready for AI-driven content delivery.