Pity the poor content audit —one of those important but unloved tasks that rarely gets the attention it deserves. We agree that it’s important, but it always ends up less important than the never-ending demand for new documentation. If pressed, you probably could list several very good reasons why you need to make content audits a routine task, but there’s one that you might miss, because it’s not as obvious.
One key reason to regularly audit your technical content is to identify where rot has set into your documentation. Or more precisely, ROT: Redundant, Outdated, and Trivial content. You see, I noticed that when I’m searching for information, I tend to avoid content that isn’t sparkling and fresh. Not ROTting, but just little stale.
When I’m looking for an answer, I attach value to the publication date of content. So while a beginner’s guide to technical writing might be useful for years, I’m going to be suspicious of any product documentation that’s more than a year old. In fact, given the typical pace of software release cycles I worry about the accuracy of any documentation more than a few months old.
I’m going to be wary if your product documentation was last updated back in 2010. After all, that was four iPhone generations ago!
Clearly I’ve internalized the pace of change that I see in the world of high technology, especially software and services. I know that in many cases it’s ridiculous: is a book about content strategy written in 2010 any less useful than one written last year?
But even though I understand the vast majority of information that we find online is still valid after a few years, I’m just used to products that are updated regularly. Here’s a common example: check your phone: how many updates are waiting to be installed? Even if you update regularly, you’ve probably got four or five updates waiting for you.
When I search for the answer to a question, I always consider when the information was created or last updated. If I want to know how to change settings on my phone, a help article from 2009 probably won’t be relevant and reading it might be a waste of my time. I’ll use it if there’s absolutely nothing else available to help me, but I’ll always start with the most recent information.
When your customers have a product question they’ll have the same reaction. If they can search your documentation by product version (and if they remember which version they’re using), they’ll start there. But if you last updated the help content for that version three years ago, you’re telling them that you’re not actively supporting the product.
If potential customers can view your documentation (something I’m all in favor of, but that’s a different column), consider the image that you’re presenting when they see stale content. These days technical documentation is part of the research phase of the buying journey. Your stale content tells them that the documentation isn’t a priority for your company, and that discredits their primary source of technical information and help for your product.
It’s the online equivalent of cobwebs in the corners, paint peeling from window sills, or uneven paving stones. Nothing that’s a major problem now, but put together the present an image that fails to inspire confidence. If the company allowed these things to go without attention, then what else did they decide was not important enough to fix? Customer support? Invoicing? Product bugs?
Even if your technical content is correct, relevant, and useful, your customers will doubt its accuracy if looks old and infrequently (or never) updated.
Customers and prospects may also mistake stale content for redundant or trivial content. If no one has touched the content in years then it must be unimportant, right? Maybe the information was copied to another page that is updated more often. Maybe the content was forgotten, or ownership was lost in a corporate reorganization. Your customers neither know nor care about the reason, all they see is stale content.
So how can we avoid stale content? Instead of making a superficial edit to update the Edited On date, use this as an opportunity. Create a plan to identify stale content and then give it a quick review. I can always find a mistake (or two, or twelve) in anything I wrote more than a few hours ago, much less a year or two. In fact, regular reviews should be part of your overall content planning, so include a post publishing review date when you first add its creation to your schedule.
Nothing ages faster than technical documentation. Even if it hasn’t entered the stages of ROT, once it starts looking stale then it looks less attractive to your customers. Day old bread might be a deal to someone, but it’s not what you want to serve to VIPs.
It won’t take much to turn your stale, musty content into fresh, appealing content that will impress your customers. Spend a couple of hours updating those screenshots from three versions back. Add those links that you always meant to include. Incorporate that troubleshooting tip that your support team sent last month, or update a couple of concept topics with the hard-won experience you’ve gained over the last year with the product. You’ll clear tasks off your list, and your customers (and potential customers) will feel confident that you will keep them supplied with fresh, relevant documentation.
