An Alchemist’s Quest: Designing the Enterprise Content Model

Content is a business asset. It’s gold for companies that manage to leverage it. Many have recognized its potential, but few have managed to make this a reality. Much like the goal of alchemy which was to turn raw matter into gold, the goal of content modeling is to turn masses of obscure content into a manageable business asset, one that:

• Drives growth in measurable ways
• Reduces costs by being easy to retrieve, reuse, and automate

A content model is a bit like the Philosopher’s Stone, the medium that turns raw content matter into gold. This is the story of how we went in quest for that Philosopher’s Stone at IBM.

Setting the scope

I had stars in my eyes. In 2016 I joined the IBM Content Center of Excellence with a mission to design an enterprise content model and tie it to customer experience metrics. This was an information architect’s dream job! Just imagine: 230 million public URLs. Several thousand content authors across the globe. Content stored in multiple systems: WebCMSs, CCMSs, KMSs, and all the MSs you can think of. The challenge was awe-inspiring.

Some sobering doubts crept in quite quickly, however, when I started talking to the heads for content for marketing, sales, training, documentation, and support that were part of the workgroup. What was it that we were modelling exactly? And what for? This had serious implications on what to include in the model and its level of granularity.

Granularity

“Alchemy is the art that separates what is useful from what is not by transforming it into its ultimate matter and essence”
-Paracelsus

The first question that arose when I started working on the model was about how big or small its constituting elements needed to be. Abby Covert summarized this problem in How to Make Sense of Any Mess, and for the content model it could be described like this:

So if the content types in the model were very vague and large—like “product content” or “marketing collateral”—it would be easy to classify content but not to retrieve or assemble it. On the other hand, if the content types were too precise, there was a good chance that nobody would bother to use the model. So the model had to be a subtle balance of precision and simplicity.

Business impact

There was also a question of business impact: of all the existing types of content that were already captured in content management systems (more than 600), which ones were only used internally, left out of use, or not used at all?

We had to come to an agreement as to why we were creating this model at the enterprise level, while various groups had some models in place. We needed to make sure that the link between content governance and organizational efficiency was explicit in the communication about the purpose of the model.

We wanted the model to be strategic – that is, that the model only included content that served a well-identified business purpose. For example, FAQs were not considered strategic because the business purpose was not clear.

Finally, we wanted the model to be about digital content only. That is, it excluded print material such as flyers and posters, which simplified things in a way, but it also meant that UI copy and social media were included.

Defining “content type”

I had an “aha” moment watching a webinar by Carrie Hane and Mike Atherton: we could use domain modeling techniques to design the model! We went for their proposed definition of “content type” as “a unit of purpose and structure”:

• Unit: it must be able to stand on its own, no matter how big or small it is, and whether it can be embedded within another content type.
• Purpose: it must provide an answer to a customer need. For example, “video” in itself is not a content type, because it can answer multiple customer needs. On the other hand, “demo” is a content type because it addresses the need to see step-by-step instructions for doing something.
• Structure: no matter how it gets published, it includes the same elements. For example, an interview will always include a title, an introduction, and questions and answers – whether it’s a video or a transcript.

Scope definition was a very important phase – you can easily get overwhelmed by the complexity of enterprise content. In alchemy, raw material is often associated with chaos, and a structured, systematic approach was needed to proceed.

The modeling process

“The secret of life, though, is to fall seven times and to get up eight times”
-Paolo Coelho, The Alchemist

The master plan

We used an iterative approach to designing the model.

We divided the project into four iterations, each iteration being made of two sprints: one for research and design, and the other one for group validation and synchronization with enterprise taxonomy systems.

Inventory and interviews

We started with a dual inventory. We asked content managers to provide a list of their content types, and, in parallel, our enterprise taxonomist made an inventory of existing content type taxonomies across content and knowledge management systems.

We ended up with a list of more than 600 types of content, which with the balance of precision and simplicity in mind, we aimed to synthesize down to a more manageable 50. I interviewed content managers about the lists they had provided. For each content type, I asked them about the purpose, the structure, but also about who created that content and how. I also asked them about differences and similarities with other content types (from their own list, or from the taxonomies, or other content managers’ list). I also interviewed content authors. While the heads of content at the corporate level had a good idea of the existing model and how it was supposed to be used, content authors could tell me about how they were actually using it.

Working with the enterprise taxonomist, we were able to start making some rough mappings. For example, one team’s “success story” was pretty much the same as another team’s “case study,” so we agreed on one entity to describe this type of content.

Card sorting

To push the mapping further, we organized a card-sorting exercise, in which we involved both content managers and content authors from all part of the enterprise. The cards had definitions, and the categories were the names of the first consolidated list of content types we had identified. From the card sorting exercise, we identified the types of content that were unclear.

Review survey

We reviewed these types and then sent a company-wide survey to get feedback on the first iteration of the model. We managed to validate complete definitions of content types based on the following template:

Journey mapping

“Everything you need to know you have learned through your journey”
-Paolo Coelho, The Alchemist

Finally, to create a visual, consumable deliverable from all that modeling work, we did some journey mapping.

The journey map helped us make connections between content types, audience, formats, stages of the customer journey, emotions, and lifecycles.

Voilà! It might sound like this was all rosy, however, linking the design to its implementation was challenging. What’s the use of a content model if it cannot be instrumented? It needs to be integrated in tagging and search systems, processes, and authoring tools to be of real use.

Challenges

Lack of visual content modeling tools

The first problem was in the tooling to create the model. We used a mix of spreadsheets, shared collaboration walls, mind maps, and taxonomy visualization tools. But there was no tooling available to do all of these things in one place. We wanted something to help us collaborate on the modeling and then generate something that could be used directly into a taxonomy.

Lack of enterprise taxonomy tooling

The second problem was in the convergence of the various taxonomies across the enterprise.

We added the enterprise content model, not as a new taxonomy, but as a new view on existing taxonomies. So our model was not trying to reinvent the wheel, but rather was providing the synthesis and mapping to bring all of the existing models together.

It was a good thing that the model did not impose a re-coding of all CMSs (not that this would have ever been possible), but having a taxonomy was just a first step for enforcing its adoption.

The model in action

Even with these challenges, the model had measurable impact:

• It initiated conversations about content effectiveness. If each content type has a purpose, how do we measure it is fit for it?
• It helped identify areas where we could become more efficient as an organization: when different teams realized they were working on the same type of content, they started collaborating.
• It made the concept of “Minimum Viable Content” become a reality, with teams using the journey map to select the most important types of content to include, for example, for a new product.

Taking the model further

We managed to get organizational alignment with this content model, and in the process we discovered that it was just one piece of a broader taxonomy puzzle.

To link the content model to our customers’ needs, we needed customers involved in every phase of the project (inventory, card sorting, survey, journey mapping). Doing this provides a tighter link with intent modeling to capture the language customers use when they look for a type of content and to make sure the language we use internally matches how our customers describe it.

This is where the quest for the Philosopher’s Stone that turns raw content matter into gold took us thus far. The practice is maturing and more and more content alchemists are joining the quest. Content strategists who want to demonstrate the value of content must get interested in information architecture so that they can build their Philosopher’s Stone and turn their content into a manageable business asset.