Dee Beck, McAfee
June 1, 2019
Today McAfee has a live, customer-facing documentation portal (docs.mcafee.com) that hosts multiple versions of 60 products translated in up to 20 languages. Despite achieving this milestone in 2017, we have a long way to go before we deliver truly personalized content. Launching docs.mcafee.com has been just one step in the journey.
To get to where we are today, we had laid down a solid foundation nearly a decade ago. DITA XML was that foundation. The topic-oriented writing on which DITA is based is a crucial piece for personalization. Writing topics allows content to be re-organized in different ways for different purposes. The separation of content from presentation that XML provides is another important piece for personalization.
Another foundational piece was implementing a Component Content Management System (CCMS or CMS). The translation cost savings that we realized from moving from desktop publishing tools, like Adobe FrameMaker to XML were significant enough to justify the cost of a CMS and at the time we translated into only seven languages.
Our first try
With DITA and a CMS in place, we were ready to deliver personalized content to the web and we were successful…or nearly so. We did succeed in personalizing the content, down to the field-level in custom software builds. Although the customer experience was perfect, the system architecture was unstable and affected performance. Even though we had to eventually roll back this work, the project provided something valuable. It proved out the flexibility of topic-based writing. Because our authors had followed the principles of topic-based writing, very little of the existing content needed to be reworked and the system presented complex combinations of content with relative ease.
A primary driver for moving our content to the web was data, data, data. We needed data about how customers were or were not using our content and in which languages. We wanted data to prove the value of product documentation, but we also wanted to understand what content was most important. Bottom line: we needed data to make decisions based on the customer experience.
Second time around
Our second attempt to move to the web had less lofty goals, but it’s timeliness was essential. What was the minimum amount of effort needed to get our content on the web, so that we could start collecting data? To expedite results, we had to go with what we had. Our existing document types— like installation guide and product guide—became our “taxonomy.” Since the taxonomy drives architecture and design, we didn’t so much create a web portal as we did put our PDF guides on the web. But it was a success…or nearly so. The customer experience fell short in a couple of main areas: architecture and SEO.
To solve these issues and help us continue in our journey, we changed the way we work. We broke up our centralized tools team and formed discipline-based working groups. Group disciplines include information architecture, analytics, content strategy, UX research, and governance. The working groups are separated by discipline to develop discrete talents and knowledge, but collaboration across groups is expected, necessary, and will be actively facilitated.
The biggest change facing us in the next step in our journey involves moving from product- and book-based content silos into content collections that include content across products. Driving this changes the fact that our customers don’t use our products in isolation. Through our working group model, we are rethinking our entire approach to align with how our customers use our products. Activities in our 2021 roadmap include building a controlled vocabulary from scratch, gathering data from multiple sources for analysis, and defining new content and metadata models to support subject-driven content collections.
As you can see, we have plenty of work ahead of us. Using knowledge from past successes and failures and our focused working group approach, we are moving forward in our next step towards personalized content delivery.