Proof, if more proof were needed that keeping the user in mind when designing a product, document or website really does work.

Renewing a support contract with a client, I was asking them if the website had been beneficial and if there was anything about it that had worked well. The response wasn’t quite what I’d expected, so I can’t take full credit for this, but it’s worth bearing in mind. Amongst various comments, one stuck out:

“… and a lot of people have commented on the fact the photos aren’t ‘glossed up’, you get a real sense of the workmanship that way”

For example, if you look at this photo page you can see that the photos used were taken by the client on a small digital camera. When I received these photos I pulled them into PhotoShop and started filtering and tweaking them, but no matter what I did to them the end result was the same.

They didn’t feel “honest”.

It’s hard to elaborate on this without sounding rather twee but ultimately I liked the fact that the photos LOOKED real, they didn’t looked staged and lit like a professionals photograph. Unwittingly I was wearing my user cap and seeing things from that point of view.

I wish I could say it was a conscious decision but it wasn’t, but it does seem that after spending many years wearing many different professional caps as part of my job as a Technical Writer, I can now flit between them without even realising!

I guess there even may be a lesson here for anyone selling something online. The more “real” you can make your product appear on your website, the better. Which reminds me, I’ve got some stuff to sell on eBay, maybe a video would help?

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.

Ahh the joy of site stats and referrers. With them I may not have spotted that some kind soul had added this humble blog to the Tech Writer Blog Directory.

Whoever it was, thanks! (yes, I’m guessing it was Tom). I’ve updated my details, stopping short of listing all of my websites..

To everyone else, if you are a technical writer, or just work in the field of technical communications, and if you have a blog that should be added head on over there and add it. It’s a Wiki page and is open to all to be edited.

I’m a big fan of directories (I run the Scottish Blogs directory, as finding other blogs in a ‘niche’ is always somewhat tricky. If nothing else the directory provides a starting point from where you can explore.

It’ll be interesting to watch this list grow as well, as I’m sure it will, and there may come a “tipping point” when the Wiki approach is no longer viable, but that’s some time off I think.

In other news, I have a few posts almost ready to be posted here, but I’m a tad busy at until later in the week. I really want to “up” the postings and see what I can do with this blog, and I guess the first thing will be to post regularly and build an audience.