It’s a question we hear sporadically here at Armada on the Technical Writing, RoboHelp, FrameMaker and Flare training courses we run – do we class the profession we’re in as science or art? Are technical authors scientists or artists? Some people have strong opinions on the subject; and of course not everyone agrees. The question is related to another which provokes even more discussion – what’s more important, the content or the aesthetics?
Have you got an opinion? Probably! See if it matches mine…
Let’s start with some analysis – just as we do in our day jobs. Science is the systematic study of the behaviour of something by observing and analysing. Art often involves a creative skill and some kind of performance or production. They seem miles apart.
When we, technical writers, are at work, what is it we do? We observe, analyse and record processes, situations, subjects. But we do far more than that (at least we should do!). Because although the methodical analysis of the observations is important, what we do with the information we’ve gathered is crucial. Firstly, we need to decide what information is needed – something “needs documenting”, a product, software, application, hardware, equipment, or whatever, but we must know exactly what, how and crucially why.
When we start the analysis, all sorts of early questions need answering, without most of us being aware of many of them, such as: who needs to use the product, what are their skills, reading and understanding abilities, how should we educate them, what do they want to do with the product, what is it capable of, what is the best media and technology to use? And that’s before we consider the structure of the help or manual, the writing style, the level of detail, the aesthetics, and a thousand and one other points.
The majority of these early questions have much to do with creativity, i.e. art, and not systematic production, i.e. science/engineering. Even the decisions which seem to be solely related to usability are rarely black and white decisions; they are ‘shades of grey’ choices influenced by both feelings and reasoning.
This is part of the reason why a quality technical writer is not an android that churns out one homogenous topic/chapter after another. To produce quality user documentation requires creative thought and flair. Sure, there are plenty of days when we write sections in a manual or topics in a help system that, for very good tech writing reasons, are simple and very similar to other sections or topics. But much of the time most technical writers have to consider many other things – the use of imagery, colour, language, etc. – i.e. things that are eye-catching or memorable to users. Making the help or manual visually appealing and linguistically interesting (whilst remaining clear) should be welcomed. Indeed, on occasions, bending the style guide rules (be careful who you say this to) may be exactly what’s needed for documentation to be the most engaging.
All of that said, at the very core of our writing, we must strive for the ABC – Accuracy, Brevity and Consistency. There’s little point in user documentation that is inaccurate, verbose or confusingly inconsistent – users will simply not want to use it. Therefore, the analysis and writing needs a scientific methodological approach.
Furthermore, while some art can exist without a reason – art for art’s sake – this is not so with a technical manual or help system. It needs a purpose. But this is true of so many things: buildings, vehicles, furniture, clothing, etc. They exist for a reason; it’s vital that they are functional, but if the building is just a concrete box, or the vehicle unpleasant on the eye, then it fails to be appealing and won’t be used. But let’s turn those examples around: a building that looks interesting but is poorly constructed, or a vehicle that is beautiful but unreliable and uncomfortable, also won’t be used, and indeed may be dangerous. In other words, both the functionality and the design are important.
For me, this demonstrates that technical writing is not strictly science but nor is it strictly art. It’s a healthy combination of both. To excel as technical writers we need to both think and feel, focus on the detail while being aware of the big picture, be consistent yet flexible. Be scientific. And be artistic.
So, that’s my opinion. Does yours match mine? I’d be interested to hear – just leave a reply below.