It’s going to be a big year for us, both as a company and as a team. We have grand and achievable plans for the product which will mean the working processes for the Publications team will need to change for, as well as multiple streams of work with their own staggered release dates for the product, we are also restructuring our entire information set to improve ‘findability’.

Which immediately prompts a question, how do you improve ‘findability’?

The simple answer is would be ‘in as many ways as possible’ as there is no silver bullet. What may work for some, won’t work for others. However we have to start somewhere and the first thing we can do is restructure the architecture of our information, slimming down the content where possible with an eye to adding new formats of information.

We have already successfully piloted some new formats of information and will continue to roll more of those out for different areas of the product (in essence, these new documents are a high level overview of all the levels of an area of the product, from concept and usage to API implementation), and the signs are that the restructure will go a long way to meeting the needs of our customers.

Having been lucky enough to speak directly to some customers in the latter half of last year, I know that we are on the right path. The challenge will be to keep moving things forward amidst everything else. It’s going to be a busy year and already the analogy is one of a juggler who is keeping things in the air… for now!

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!

Part way through April and the discussions and planning over the past few months look like they are, slowly, starting to come together.

The plans are ambitious, not only are we restructuring our information offering to make things easier to find, we are also attempting to change the way we document our product. Moving us away from a set of information that covers “here is what our development kit can do”, to content that says “this is what our product does and how you can extend or modify it”. In one way it’s a subtle shift, but the ramifications are still unfolding.

One area in particular will be interesting, namely that we will be asking “why that way?” a lot more than we have in the past. In the past, as we were light on content in several areas, we steered away from such questions where we could, but now we need to tackle them head on which, invariably, will mean we will start to drive some interesting conversations about how our product SHOULD be used.

None of this is, as ever, rocket science, but there is a level of change management that we need to consider.

In the end we should end up with, in essence, an information matrix.

Down the left side will be headings corresponding to the types of content we have (or need to write), and across the top will be a list of the areas of the product we document. I say “will be” because we are still trying to fully understand what those areas are, and to make sure that the terminology we use will be understand and used consistently across the company. Once that matrix is in place, we can audit what we have and see where the gaps are.

Thankfully, once we understand the new structure, the act of restructuring the information will be easy. The joys of single source, topic based authoring!

I won’t, however, mention the third level of complexity we are trying to tackle as I’m not quite sure I’ve got a handle on it yet. Suffice to say that we need to make sure the new information structure we decide on within the product documentation, also needs to fit into a wider piece that is being introduced to our developer community website (same basic idea though, creating landing pages on ‘topics’ or ‘product areas’ to direct users to product documentation, elearning material or support notes).

It’s a bit like doing a big jigsaw and at the moment I’ve only just managed to finish the outline.

Random thought: Has the rise of (talk of) emotional content (affective assistance) been driven by the concentration, over the last few years, on technological solutions?

Single sourcing, XML, DITA, DocBook, and all the rest have (rightly) taken our profession forward, so I guess it’s natural that the general trends, as well as refocussing on the content itself, are looking for how to better engage with a modern audience.

The evidence suggests that that modern audience is Facebooking, Twittering, and blogging, and wants content in easily digestable chunks.

That plays nicely into the hands of single sourcing (chunks) and the idea of emotional content through connecting to the user, using friendly language to make the content easily digestable.

So, if you’ve already got your technology sorted out, why aren’t you looking at how your content is presented?

I’m currently in the midst of some thinking. I’m thinking about how we can improve what we do, how we measure those improvements and ultimately how we make a step change in the quality of our output.

Oh no, I used that word, didn’t I.

Quality.

At this point I will veer away from that word, for fear of plunging headlong into the land of metrics, and instead outline some of the things floating around in my head.

To improve the perceived quality of the information, there are some things we can do:

• Improve the navigation
• Improve the findability of the information
• Improve the technical accuracy of the information
• Improve the completeness of the information

Navigation and findability are linked and we have some ideas on how to tackle those through better indexing, better understanding of the structures, addition of signposts and all those good things.

Improving the completeness and technical accuracy can be a little trickier to nail down though. No product documentation is ever complete but by improving our approach to collating information and the questions we ask, we can take start to make improvements, those same questions should also help improve the technical accuracy, as will a beefed up review process.

With all of this in mind, we will be running some workshops early February to revisit the basics. We will cover off every aspect of how we work, and step through how we can improve the outputs of all our hard work (well, all the hard work the team do, I mostly try and keep out of the road thesedays, they seem to work better that way!).

I’ve been with my current company for four years and, for each of those years the team have managed to make significant improvements in a variety of areas. Year One, the first members were hired and we set about improving the quality of the content, Year Two we launched our developer website as a means to make it easier to access the content we were creating (that website is about to relaunch in it’s third iteration), Year Three we transitioned from FrameMaker to Author-it and publish our Knowledge Centre to the developer website, and this coming year… well, time will tell.

I’ve no idea what we will decide to do, what processes we will change or adopt, what new ideas and challenges we will set ourselves, but this part of the job is the one I enjoy the most. Everything is fresh, new and exciting.

Roll on 2011!

As the end of the year starts to draw close, inevitably thoughts turn to 2011 and the challenges that may lie ahead. From a product point of view we are starting to get a feel of how the year will shape up, and so we can start to look at how our team negotiates the (still forming) landscape.

It already looks likely that our aim (alongside keeping pace with product development) will be to get to a point where we can correctly focus our efforts around structure, and ad-hoc document requessts. Given that we have access to outcome codes from the Support team, several of which are specifically around product documentation being either wrong, missing, or not read at all, and we will soon have a full set of analytics from our online product documentation, which should put us in a much better position to correctly prioritise those additional work streams rather than fall into the “whoever shouts loudest” model we are currently prey to.

The analytics are powered by Google Analytics and track visits to each topic of the documentation set. The numbers should help point is to areas of the documentation that, for one reason or another, need some attention. This works both ways of course, a high number of views indicates a lot of people using the information, but where are they going afterwards? If they head to the Support area of the website then can we presume the information isn’t correct? And those topics with little to no views, are they not used because they can’t be found?

I’m a little wary of spending too much time analysing the statistics and initially they will be used purely to direct us to the outliers, those topics that for one reason or another are causing anomalies in the reported numbers. Once we smooth those out then it will require a lot more deep-dive style root cause analysis which, as with everything else, will bring a fresh set of challenges and hopefully some new routes of communication with our customers.

(note to self: stop with the jokey bad grammar, peoples might think you cant be writing good)

I’ll say this quietly because I’m a little apprehensive but, for the next few months, it looks like we will have extra resource in our team. Basically we are ahead of the curve when it comes to recruiting so, until the rest of the R&D team catches up, we are one technical writer up!

Which means that we are taking the opportunity to both get ahead with some things, and catch up on others, and one of the things we’ve never tried here is to have a formal editoral review of the content. Peer review is one thing and whilst the technical content we produce is excellent, the differing writing styles and approaches each writer has does show through.

I’ll be the first to admit that I’m not all that bothered by this, simple business reasoning dictated that we concentrate on improving the accuracy and timeliness of the documentation and so, now we have done that, we can turn our attentions to other areas including findability and clarity.

The latter finds me taking on the role of Editor (I want to write Editor-in-chief just to conjure up images of a smoke filled newspaper office in the 50s), casting an eye over all of the content we produce and using our lightweight Writing Style Guide to prod and cajole the content towards something that, without being too restrictive, has a level of consistency for the reader.

As we haven’t had anyone performing that role before, it’s taking a bit of adjustment and the jokes about the “red pen” are already flying. Thankfully I work with smart people and it’s not taken long to see the results come to fruition.

What we need to figure out is how we change this model in the future so that we can all consistently edit each other’s work, lest I become a bottleneck in this process.