Content Inventory and Information Architecture
Photo by Pixabay from Pexels
A content inventory and a content audit are often mentioned together and conducted in tandem. While usually discussed in the context of web content, surely they can benefit documentation website as well. Agree?
Intro#
Among the many wondrous things generative AI can do for mortals, there is one called “read the documentation.” Promises abound that finally we can “say goodbye to digging through documentation” and embrace “instant answers.”
Whether generative AI lives up to the expectation is beyond the scope of this post (I do believe it can, eventually). AI aside, the promises are a testament to two things:
Documentation is still an important source of truth for knowledge seekers.
For a non-negligible portion of readers, finding answers in documentation is challenging.
AI chatbots trained on documentation can alleviate the agony to a certain degree, if the truth seekers know how to ask questions and validate the answers they got. As such, those in charge of documentation are not off the hook.
In this post, I’m going to share thoughts on two processes which, if adopted, have the potential to boost the findability of information, reduce the amount of “generative hallucination”, and improve workplace happiness 😉.
Know the “present”#
Say you are tasked with bringing documentation to “the next level.” To go to the next, you need to know the present.
A common obstacle to knowing the present is the sheer volume of existing content. Whether an established solution or a new service, technical documentation tends to grow: there are always things to add. Before anyone notices, documentation morphs into an unwieldy mass and the first thing people look for on your documentation website is the little magnifier 🔍, aka. search box.
Is there a solution to the dilemma, growing (adding stuff) while staying fit (keeping the navigation human-friendly)? Once we realize the cause of the issue, which is, trying to squeeze too much new content into an old framework, the solution becomes obvious. We need an information architecture adapted to the pace of growth.
When discussing the Four Components of Whole Product Technical Communication, I suggested using a content audit as a starting point to construct a good information architecture. It’s time to dive in!
Content inventory#
One prerequisite to a content audit is a content inventory, which, to put simply, is a list of content, or pages of a documentation website.
Given that our goal is the information architecture, I suggest including the following in a content inventory:
Page title and page URL: Keep them as separate fields on the inventory spreadsheet.
Hierarchy: To record the structure of the documentation website (how pages are grouped and positioned), including the top-level menu, second-level menu, etc. This is the most important attribute in our content inventory.❣️
Content type: To indicate whether a page is a conceptual piece, a knowledge article, a tutorial, an example, or a generic use case?
Other assets: To log any multi-media content that is created by other functions or not widely used in the documentation yet. For example, an infographic, an animation, a YouTube video, or an interactive demo.
Let’s diverge briefly to look at a common use of a content inventory (and why you should avoid it).
Audit for quality#
A common use of a content inventory is to manage content quality. You evaluate each page and note down the decision—to keep, to update, or to delete (archive).
However, unless the documentation has been lacking of maintenance for a long period, auditing for quality at the page level may turn out a waste of time, for the simple reason that proper solutions already exist:
Writing style and convention issues can be tackled by tech writing teams as part of their routine job.
Technical accuracy issues should be contained within scrum teams (if the organization adopts the Agile methodology) and stay a concern of the software development life cycle.
Audit for logic – In search of new perspectives#
Have you ever wondered “why this page is here, not there” when browsing a documentation website?
No matter what others say, we believe human beings act in a logical way (the folders on your colleague’s laptop might make no sense to you, till he/she explains that “red” means “old” while “green” means “new”). The content hierarchy in the content inventory aims to surface the logic why the documentation is organized the way it is: maybe it mirrors the product’s web UI, or corresponds to the functional components that make up the solution.
Photo by Scott Webb from Pexels
To go to the next level, we need to see/show things differently. A content inventory is well-positioned to help us in this enterprise.
Want to try personalized content? Add a column called “Persona” to the content inventory.
Need to map documentation to the user journey? Consider a column to incorporate product adoption stages.
Prepare for themed discussions? Maybe a column with keywords or product themes.
In short, categories (columns on the spreadsheet) are the way to fit documentation pages for various purposes, or, to apply various information architectures.
Think carefully about the categories in a content inventory, audit them to uncover new logics, form different storylines, and make reading documentation an enjoyment! 😄