Tag: <span>Content Audit</span>

I’m always wary of buzzwords and industry fads, and will always take, primarily, a business focused view on any new theory (or strategy) that I hear about until I fully understand its real life application. Such is the case with Content Strategy.

It’s something I’ve talked about on here before (under the guise of Information Strategy) but whilst I’ve a good idea of how it could benefit our company, I’ve struggled to get buy-in. Whilst Content Strategy discussions go well, everyone thinks that a coherent and consistent set of content is a good thing, where we seem to struggle is getting commitment to getting the actual work done to bring things into line. The high level Content Audit I completed about 18 months ago is about as far as we got.

So, rather than try and get everyone on-board from the outset we are now starting from the bottom up by providing a technical product information service to our sales team. Essentially, our team will be providing source content that can be used by our PreSales team to inform potential customers what our product can do. It’s an important part of our sales cycle, and will mean that we will have a consistent set of information, used across different areas of the company, all sourced and developed with a common view (and reuse) in mind.

The route we are taking towards a company wide content strategy may take us a while (my gutfeel is that, once the ball is rolling and word gets out, other areas of the company will soon come on board) but ultimately we will end up in the same place. The advantages are that we can make decisions on the way, replan a lot more easily (we don’t need to get it as ‘almost’ right as we would if we were tackling a larger amount of work) and crucially we don’t need any ‘stop the world’ moments.

I work in a fast paced company, we are light on paperwork, and whilst we apply good rigour and quality to what we do, we only do whatever we need, and are quick to change or drop processes if they bring no value. It’s a great place to work, but keeping up with the pace of change in our product is a constant challenge to the technical writing team, so this approach to tackling the introduction of a content strategy stands a very good chance of succeeding.

Naturally this approach will present some challenges, we will probably need to schedule some form of review of the work as it progresses to make sure it’s not becoming too focused on it’s initial use, and I’ve no doubt that we may have to rework some of the content later on when we have a better understanding of the big picture, but I think it will work.

And hey, life’s nothing without a challenge!

Work

The basic premise behind auditing your content is to better understand both the structure and the content itself. Conceptually the idea seems simple enough, but in reality performing a content audit can be fairly boring. However, whether you are conducting the audit as part of a single source conversion project, or if you have recently inherited a large documentation set, I’d suggest that it is an excellent way to gain an understanding of what already exists and, with little guesswork on your part, start to understand what may be missing.

Content Audits are usually one of the early tasks undertaken by a team moving towards a single source publishing model but they can also provide a clear indicator about whether you need to single source or not. For many teams the primary driver of a move towards single source comes when an additional product platform or customer is introduced, or perhaps through a requirement to translate and localise. However, a thorough audit of your content will show whether what you believe to be true is valid and may indicate that you don’t need to start single sourcing your documentation at all (you might just need to change your working practises).

As I mentioned, the act of auditing, in any form, can be repetitive, onerous and very much a chore, so my first piece of advice is to break it up into short manageable chunks and most certainly don’t try and do it all at once. Perhaps aim to do a couple of chapters a week, thus leaving you time to do fulfill other duties, keeping the documentation up-to-date for example.

For me, the aim of a Content Audit is two-fold, on the one hand you will end up with a very detailed breakdown of the structure of your documentation, and on the other you should also be able to extrapolate the types of information that your documentation holds (e.g. procedures, concepts, and so on). A key benefit, which almost comes as a bonus, is that having spent time looking at your content, you will also have a good plan of which parts of the documentation can be reused and which parts may need rewritten before reuse is possible.

If you’ve done any research into this area, you probably have a good idea of what is involved and what the aims are. But what is a Content Audit, what does it look like?

Well it’s fairly simple and the easiest way to get started is to use your existing Table of Contents. Pull that out into a spreadsheet and you have an excellent starting point, particularly if your documentation has been written in short sections. Then you need to get into the content itself, and analyse the structure in a bit more detail. Again there are obvious chunks of information that can very easily be pulled out, or broken down, into discrete chunks. Procedures, illustrations, tables of data, anything that is of a similar type and is repeated throughout your documentation is easily identifiable as a distinct unit (you probably have unique paragraph formats for these too, another quick way to check!).

A simple example for you.

All of our product guides and online help have “Overview” sections. They are, typically, very very similar. The product guide Overview is longer than that in the online help.

With a small amount of re-writing, we can create chunks for “Overview” and an “Overview Extension”, with the former being used in the online help, and the latter appended when used in a product guide.

Ultimately a content audit will involve a lot of time reading, cross-checking, double-checking, and I’d advise you grab a nice big desk (in the boardroom perhaps?) so you can layout printed copies of your documentation. I’d also advocate that you don’t try and do the entire process, across all of your documentation, in one fell swoop. Pausing between batches, and discussing the findings with your co-workers, will stop you missing potential re-use opportunities AND stop you trying to re-use (re-write) chunks of information that need to be kept discrete.

Once you understand your own content, then you can start the process of seeing how it stacks up against the content created in the other areas of your company. More on that another time.

Work