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.