I’m currently cruising high in the sky above the USA, on my way from San Francisco to Boston. It’s part of a whistle stop tour of two of our offices here which have teams of software engineers, architects and product managers (no technical writers though) that are building part of the product we will be shipping early next year.
During a chat with a couple of the product managers there was an interesting revelation. In describing the approach the team takes when it comes to writing documentation, the two product managers both smiled with relief when I said that we didn’t really spend much time on simple procedures, instead we try and concentrate on the why, on decision support information. We work with the support team to catch any areas of the product which are causing problems with a view to improving the documentation in that area as well, and overall we understand that the people using the development platform are usually smart, technically minded people, so we ask smart, technical questions of our development team.

The thing is, that’s not really a revelation for me. It’s something we’ve been doing for quite a while now, so much so that I can forget that for a lot of people the term “product documentation” is often seen to be fairly rote task-based, step by step procedures with little in the way of explanation.

Whilst that’s handy when you are still learning a new product, pretty soon that information becomes useless.

Thinking further, the decisions we are making during our current restructure project reflect this thinking as well. One step that was very interesting was asking some of the given audience of our product (our own developers and professional services staff) to do a card sort of some of the topics. They all have a mental model in their heads of how the product (and so the supporting information) is structured. Anything outside of that was a real problem for them to deal with.

It’s that problem area where asking why, and producing supporting information that helps the user understand how something works is far more important than simply telling them which buttons to click.

Since our companies merged we’ve had a lot of discussions and sessions to help the other engineering teams get up to speed with our platform, it’s been a bit of a rude awakening if I’m honest, as there is a lot of knowledge still floating around in the heads of some of our developers.

So it looks like the task next year will be to change that, to make information and the dissemination of it much more a key part of the software engineers thinking. I’m not quite sure how we are going to manage it but I do know that we have to create a new normal where information sharing, product information and an understanding of who is using our product needs to be much more front and centre in our thinking and our working processes.

I don’t know about you but I’m getting fed up trying to make everyone realise the value of what we do. Technical Communicators of the world unite!

Why is it so darn hard? Isn’t it obvious? We live in a so-called “information age” after all, so why is it such a struggle to get the message across?

So, for the meantime, I’ve stopped.

My team currently has a separate stream of work looking at how we get better at PR and whilst that runs its course I’ve decided to deploy a different tactic, one which has fallen into my lap. No more will I go cap in hand to department heads, no more will I try to coax, nudge and cajole others into understanding why product information is so important. I won’t roll out the usual reasons, and I will save my “part of the product life-cycle” spiel.

You see, we’ve been receiving requests from different parts of the organisation, based on some work we did in the past. Lots of people are looking for help. At the moment, all of the team are busy but I’m going to pick one of the requests and find a way to get it actioned. That way we will get a quick win and increase our profile a little (it really is great to be part of such a good team, their work speaks for itself) and it should give us an ‘in’, an opportunity to build a relationship with a different part of the business, learn how they work and in time expand what we do as part of our service to them.

Land and expand. Simple really.

At present I know there are many areas of the company producing content. I also know that many of them would benefit from our input, just as I know we don’t currently have the resource and, without a lot of up front research I’m not sure I would be able to guess at what resource would be required to cover the current requirements. Creating the business case to expand operations would take time, and even then a lot of the effort goes into educating people as to why consistent, reliable, re-usable product information is a “good thing”.

With that in mind, getting a foot in the door (landing) before getting involved and agreeing a level of delivery for the future (expanding) seems the most sensible way forward. It allows us to get a feel for where we can best be involved and over time we can increase our influence, and standing, within the company.

Now, where I can buy some ninja costumes?

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!