Having been off work for a few days (a bad cold, I’ll live), and when not sleeping, sneezing or blowing my nose, I’ve been thinking about this blog and if I can commit to a more regular schedule of posting.

The recent posts on Consideration Layers were, I hoped, designed to prompt comment and discussion, two things that I can’t seem to make much headway into here. I have pretty good RSS reading figures but this remains a small blog, with a low numbers of readers.

Whilst I do try and keep a reserve of possible topics, I still tend to react to things when posting here but hopefully the coming months will change that.

For one, we are getting close to starting our journey towards single source at work, so I’d imagine there will be plenty of things there that will spark some blog posts here. I’m also hoping to get to a couple of conferences later in the year and they are always good for getting the creative juices following, and stirring up some enthusiasm.

Until then I’ll just take things as they come. Unless anyone has any suggestions, questions or comments?

I had planned to write more about this idea but as yet I’ve not had the time to properly flesh out my ideas. I’m also taking the lack of comment on this as a good thing (everyone agrees) rather than a bad thing (no-one is reading). So, to try and briefly summarise what it is I’m blithering on about, I thought I’d try a different tact.

Namely, a diagram:

There are multiple paths down through the layers, with each layer and each consideration being linked to one another. There are some things I’m still ironing out but it fits the way MY brain thinks. What about yours?

Ahh the internet is full of simple pleasures, like Wordle.

Give it the URL of your blog, a chunk of text, or your del.icio.us username and you get something like this (click for fullsize, requires Java):

As a technical writer, every decision you make is influenced by several discrete things, considerations for either the audience of the information, the process you’ll need to follow to collate and verify the information, and so on. Every decision requires such considerations but is it possible to model these?

Some background first; I don’t revisit my old posts nearly as often as I should and, as there are certain topics that I tackle with the vague idea of covering in greater detail at some point later on, it’s handy when someone else gives me a nudge about an old post (namely, The tool is not important).

That said, such topics are typically the hardest ones to consider, the big picture things that end up with my brain reeling as I try to narrow down this wonderful profession into something digestable without generalising (genericising?) so much that it becomes worthless. Still, that’s never stopped me trying, so I’ll bash on and see what falls out of my head.

My post about how the tool is not important looks at the other areas that need to be consider if you are investigating upgrading or changing your main authoring tool, and was largely prompted by our upcoming move from FrameMaker to Author-it. The post is focussed on tools (obviously) but looking back it only mentions a rather large consideration in passing, namely “focussing discussions on the audience, the expectations”.

Such is the way of things when it comes to Technical Communications, anytime you take a step back you realise that there are many things to consider, all of which impact on one another even though they are distinctly different. The audience requires to have information delivered in a particular format (technical consideration), and in a particular voice (writing theory). They’d also like it structured a certain way (information design) and of course they’d quite like it to be accurate and up-to-date (working practice).

As a manager of a technical communications team, all of these things feature in my thinking almost every day. Anytime something new lands on my desk or a new issue is discovered that needs to be corrected my brain runs through the gamut of considerations trying to figure out how best to tackle the work. The more often this happens the more I look for a model of how best to tackle such things and, as I’ve not really found one, I thought I’d take a bash at creating something myself.

This is a first draft, it is still very crude and is missing a lot of detail but as a starting point I think it might work. The premise is simple enough, for each piece of work undertaken by a typical software technical writer (yes, I’m making some assumptions), there are various items that need to be taken into consideration and these can be broadly broken down into four layers - Audience, Content, Theory, and Tools - and within each layer there are a number categories of consideration.

Rather than try and tackle the entire thing, I’m going to focus on the big pieces first.

The following layers are the broadsweep of the model, and I think most technical communication considerations can be allocated to one of the following;

• Audience - be it preferences for format and media, scenarios for which they require information, through to a detailed understanding of how they work.
• Content - the main output needs to be considerate of audience, and as such will be provided in different forms (written, graphical and so on). It also needs to be sourced properly, written, reviewed and published.
• Theory - depending on where you are on the IPMM, this layer may be thin but it will still exist and covers working practice as well as in-house guidelines. It also covers larger view methodologies such as single source, minimalism in writing and so on.
• Tools - the lowest layer as it is furthest removed from the user but still has a significant impact as it is directly tied in to the writing process itself.

So, does any of this make sense to anyone? Or is it just me? Over the next few posts I’m aiming to delve a little deeper into each layer, presuming I’ve gotten them correct and we’ll see what lies within.

Consider this very much a work in progress, and feel free to point out my errors. Comments are welcomed.

No-one reads the documentation anyway, so why do we persist in writing user guides, instruction manuals and all the other types of document-centric information silos that we all quietly loathe creating in the first place?

Unless you have a contractual agreement to compile information into a document, it’s our job to figure out how best to get the right information to the user at the right time. It’s down to us, no-one else.

And I, for one, have failed to do my best, instead I’ve hidden behind the usual arguments of “ohh but that was how it was when I got here”, or “we don’t get to speak to our users so it’s hard to know what they want”.

OK, so I’m deliberately setting out a pretty bleak scenario here and, like everything, your own situation is probably not that dire, or is certainly further towards the ‘good’ end of a sliding scale.

However, the fact remains that a lot of thought and effort goes into creating content and perhaps not enough is placed on the delivery of said content. The mediums of the past are still valid but are increasingly being replaced and (and this is important) these new mediums are part of customer expectation.

I need look no further than myself to give you an example.

I am fairly careful with my money in that I tend to do a lot of research before buying a product. Whilst I have just purchased an iPhone, I didn’t buy the first version because my research suggested it would’ve been a mistake.

Part of my research is, quite simply, to see what kind of supporting information exists for the product I’m considering purchasing. Can I download or view the product documentation, and if so, what format is it in? What about user forums or support websites? Knowledge bases and articles? The latter are, increasingly, higher up my preference list than the former to the point where I’m pretty sure I’d buy if it had no user guide but a thriving user/support forum.

That’s not to say that there isn’t a place for our old friend, the product manual, but I would suggest it is under threat. Previously, to receive validated and trusted product information, I’d go to the product manual or support staff, anything that was produced by the people that make the product.

Now?

Now, thanks to reputation systems (points system that users build up the more the offer to, and interact with, a website) and the ability to cross-check information quickly and easily on the internet, I am far more likely to trust a post or article written by a complete stranger.

The wisdom of the crowd comes into play here of course, the more people that use your product the better the chance of a unique and useful scenario being documented and published, but there is no reason why we, the technical writers, cannot insert ourselves into that stream. Refocussing why we deliver information is a crucial part of the changes taking place in our industry.

Because, to be frank, if we don’t start looking around and changing how we work, we may soon be redundant. In every sense of the word.

I love making mistakes. Really I do. Sure they can be painful, costly and time consuming but let’s look at the positives here, every time you make a mistake you can learn something new. How great is that!

As part of our release cycle, we conduct a series of retrospective meetings, one per team, in which we focus in on the things that went well (with the aim of continuing them) and things that didn’t go so well (so we can improve them). I faciliated some of the last round of these and this time round I get to do them all.

So for the coming week I have two, two hour long meetings a day, helping the teams discuss and formulate actions for the next release cycle. It’s a fascinating process and I’m quite looking forward to it.

The technical writers in my team are embedded within the development teams so they take part in the relavent retrospective meeting, but I’m currently wondering if we need our own mini-retrospective process.

Technical writing is such a spread of disciplines that, whilst we are well hooked into the development process, there are still some things that we do that are unique to the role and deliverables we produce. I have a few things that I noticed during the release that I’d like to discuss, some of which are under my control, some of which aren’t, but all are things that can be handled better in the future.

Making mistakes isn’t ever fun, we all have great pride in our work and do our utmost to be professional and dedicated. However a lot of mistakes come about through bad processes (or lack of them) and those are the ones that it is easier to tackle first.

So go ahead and make mistakes, it’s ok, everyone does. Just make sure you learn from them and figure out ways to stop them happening again in the future.

Just a quick note to say it’ll be a little on the quiet side here over the next two weeks as I’m going to be a little hectic. I’ve got a product release (deadline of a week tomorrow), a new developer website to launch (deadline of a week on Monday), and after that a week long series of retrospective meetings that I’m facilitating. All of that takes me through to about the 21st of July.

That plus the remortgaging of our house and the imminent launch of iPhone 3G means when I’m not here, I’ll be asleep!

Until my return, check out my TechComms RSS List (download or view online), or take a cruise on the Writer River.

See you on the flip side.