Yesterday we launched a new version of our developer community website. It doesn’t have many ‘community’ features as yet but that’s all to come. One thing it does now have is an HTML version of all of our product documentation, in an easily searchable format.

It’s no coincidence that it looks very much like the Author-it Knowledge Center as it too was built using Author-it (alas I can’t show you our website as it requires a login).

This new format of the product documentation is largely to move us away from PDF only documentation. At present we still have a set of PDFs but they aren’t particularly usable.

We ran a few quiet trials of the knowledge centre format and everyone who saw it liked it, particularly the fact you can search across every piece of information offered.

So I was definitely pleased when, after sending out a company-wide announcement about the new version of the website, highlighting some of the new features, one of the first pieces of feedback I received was about the knowledge centre and how good it was. For the, as the kids say, win!

The knowledge centre will be updated on a regular basis, so my next challenge is to figure out a way to embed RSS notifications for new/updated topics. But so far so good, and with Google Analytics in place in the knowledge centre, we can continue to make improvements to both the information itself and in making sure it is accessible.

It’ll be interesting to see how the knowledge centre is used, particularly if we manage to track it against the number of incoming support calls as the main reason we are adopting this format of information is because, many times, the answers are there, they just weren’t that easy to find.

The infinite monkey theorem states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type a given text, such as the complete works of William Shakespeare. As such, it stands to reason that two monkeys would be able to produce the same volume of output, but are unlikely to write exactly the same thing. Add in a few more monkeys to the equation and suddenly you have lots of content, none of which really relates to anything else.

I’ll stop with the monkey metaphor before I insult anyone.

Consistency is an important part of communication, even at the simplest level of having a common terminology, using the same words consistently throughout a document helps the reader learn. Take this idea up a level, from a single document to a number of documents and maintaining the same terminology across all documents can further help re-enforce the messaging and aid learning, and should give the reader a level of comfort that the entire set of information has been thought of, and delivered, as a cohesive set.

Move up the stack one more time and you start to look around at surrounding areas of information, outside of product documentation, produced by a different department and it’s here that consistency starts to suffer.

Typically Technical Communications teams will spend some time developing their own Style Guide (however loose), and agree a basic set of terminology, also known as the Product Glossary. Having been involved with creating a Product Glossary in the past, it’s interesting that other areas of the company see it as being a ‘documentation thing’, until such times as you get them to sit down and help you compose entries for it.

I know that the information produced by my team will be consistent and is written in a similar enough style that it won’t ‘jar’ the reader. In other words, it doesn’t matter who wrote the information, it is all part of one larger set of documentation, with a similar tone, voice and style.

Aiming the information at the correct audience is a key part of deciding what the three attributes of tone, voice and style, should be, and it’s at this point that I find other departments starting to struggle. Without a clear idea of the audience, and with their own perception of what the message (the terminology) needs to be, there is a tendency to wander off message, and produce a document which, whilst perfectly good in isolation, doesn’t seem to fit into the overall set of product information.

So what type of information is this? Well it varies, and can be tracked through the customer (or company) journey and their interactions with your company and product. Broadly speaking there are four levels, all of which need to be talking to the correct audience, and ideally should be providing the same message in a consistent manner.

1. First up there is an introduction, a high level chat about our product and what it can do. This is typically a mix of marketing brochures, website collateral, and sales presentations.
2. The next level of interaction delves a little deeper into the business benefits and key selling points of the product, and can start to touch on product features and capabilities.
3. After that, there is a need to provide a level of technical information, outlining the architecture and fundamental design of your product, detail the full set of capabilities, and provide reassurance around any potential implementation issues that may arise.
4. And then we get to product documentation, training material, and ongoing support and maintenance information.

Four levels of information, all of which should be saying the same thing about the product, regardless of what message that is.

It would be wrong to say that each level is unique, as each interaction your company has with a customer will vary, but largely speaking the four levels allow anyone who is creating information to better understand their audience. Add in a Product Glossary to ensure terminology is consistent, and a strong product message and there is no reason why any of the content being produced cannot be consistent.

Mapping these levels to the amount of content available at each level gives us the following:

Of course this is a very simplistic model, but as a starting point, it at least provides the mechanism for anyone about to create new content to pause and consider the audience. So whilst you could add in several levels, and several different mappings of document types, I think it’s better to leave things a little open to question as that helps bring a better understanding of why the content is being produced in the first place.

I first introduced this model to my current company several months ago, and we are currently revisiting this to make sure it is still a good fit to our needs. The next step for me is beefing up our Product Glossary, and then we can get on with the thornier issue of document management, an intrinsic part of having a Content Strategy for your company.

How early do you get involved in a project? At the start? Part way through once the scope has been set? Or once the design has been agreed? Or do you swoop in at the end and document whatever you find?

One common complaint a lot of technical writers have is that they aren’t included early enough in lifecycle of a project. The downsides are that by the time work hits your desk you don’t have a full picture of who the customer is, why they want whatever it is you are building, and how they want it provided to them. All of which directly impacts the information being created.

So how do you, the lowly technical writer, make sure you are involved early in the project? By offering your services as a master information curator, task analysis guru and all round user advocate, that’s how!

During the early stages of most projects, there will be a period when the main requirements are gathered, ensuring the pain points are covered, and that the main scope of what you are building is agreed. A lot of those discussions are largely focussed on collating information from the heads of various subject matter experts (SMEs) and stakeholders, and gaining agreement on it in a singular form.

Sound familiar? I hope so, as it’s not all that far removed from discussing a new product feature with some of the guys who helped build it, and coming to a consensus on how it should be used and, therefore, how it should be documented.

As one of the core competencies of a technical writer, it’s something many of us have forgotten we do, largely because, hey, it’s just our job. However it takes a unique skill set, one that not everyone possesses, to be able to focus a number of different viewpoints into a cohesive story.

This type of work is often performed by a business analyst, but there is no reason why you can’t fulfill a similar role to some degree. The project team get the benefits of your skills, removing some of their early pain, and you get to be involved from the get-go. Win-win, right?

Well, almost. One caveat is that being involved in the early stages of a project is likely to overlap with the end of the previous one, so whilst you are wrapping up all those little issues (you know, unmentioned features and changes) you may struggle for time if you are also helping in the early stages of the next phase.

It’s a hard balance to find, but if you really want to get in early, and I think the benefits outweigh the downsides and if needs must you may need to get support from your boss to reschedule some work to free up your time to be involved. It’s a simple enough, progressive, argument:

Understanding the customer and the requirements leads to better information. Better information leads to better use of the product. Better use of the product, lowers support calls, leads to new product features and increased sales.

Which, I think, is a pretty powerful statement to make to your boss when you are asking to clear time in your schedule so you can start this cycle.

I have been remiss at writing new content for this blog, and whilst this topic isn’t one that I said I’d post about (those posts are coming, I promise), it’s something I was discussing yesterday and so is at the forefront of my mind.

Like many people I still use pen and paper when taking notes, and regardless of the type of meeting I stick with three basic categories.

1. [] Actions either for me or my team to do. Includes things that need done immediately or things which it would be good to do in the future.
2. ? Questions on things I want to learn more about, which relate to my team. Whilst these may also be actions (typically they involve asking people questions) I differentiate them because, until I’ve asked the question, I don’t know enough to decide on whether there is anything to be done (caveat: if it is a burning issue, I’ll like put this against both categories ? [] ).
3. I Information which covers all sorts of things from useful URLs, to quotes, to product names and so on.

I also “style” my notes, with the appropriate shorthand symbol first, then a gap, then the text for that item. Keeping that consistent makes it very easy to scan down my notes to process them.

[] email report to Fred
[] speak to Tina about next phase of work
? what is the cognitive learning project, who is running it?
[] write a blog post on the Information Strategy Pyramid
I stats for last week 103 open, 74 closed

Processing the notes, again, depends on the type of note.

For actions as, unless they can be done straight away (I think that is a GTD methodology thing? If it takes 1 minute to do it, and 1 minute to write it up and put it in a list, then you are better just doing it), they are transcribed into an online task manager application I use called Remember the Milk. It has a very nice iPhone app which makes it easy to “take my list” with me at all times.

Questions are simply a matter of being asked. That may drive further actions or information which are captured accordingly.

Anything I’ve noted down as information is either processed electronically, if it’s something online I’ll visit it and either bookmark it in my del.icio.us account, add it to my list on Instapaper (again, which has an excellent iPhone app), or grab it and store for later in Evernote (again, a useful iPhone app helps).

Whilst all of that seems like a lot of work, it’s very maintainable, and I spend less than 20 mins a day processing my notes. However it helps me keep on top of several different streams of work, and so far it hasn’t let me down. I’ve been using the shorthand symbols for a long time now, but obviously the electronic processing of these things is new.

So, what about you? How do you take notes? Are you a mindmapper? A random scribbler? Or do you, like one lady who attend a presentation I did a few years ago, do you draw out the subject and the notes in one go?