Technical Writing Other Than Software

−0

This is one of the great debates in technical communication. Do you need to be a technical expert or is it enough to be an effective communicator? Different tech writers, and different employers, come down on different side of this debate.

I think there are two main factors to consider here.

First, good writing, fundamentally, in not just about good grammar, it is about knowing what needs to be said. Saying the wrong thing in beautiful words is of no use to anyone. Saying the right things in clunky words is less than ideal, but still usable. So the question is, how easy is it to figure out what needs to be said? Chances are that the engineers who built the product don't know what users need to know, so it is not use asking them. When we were mostly documenting home and office software applications, technical writers were themselves home and office software applications users and so they had a pretty good idea what needed to be said. But when nobody knows what needs to be said, you get documentation that is engineering bafflegab. A writer may strip out the jargon, but the content is still not what end users need to know.

The proliferation of desktop apps has largely ceased. Most people know how to use them. The consumer action now is mobile, where apps are much simpler and easier to figure out. Therefore there is less demand for this sort of tech writing.

Many of the people who were doing desktop software tech writing 15 years ago have transitioned into more developer-oriented tech comm or into more marketing related roles. If you are writing for a developer audience, you don't naturally know what developers need to know about a product unless you are a developer yourself. But at least those tech writers have had the benefit of working with developers for a long time, which certainly helps.

For non-software-related tech writing, though, knowing what the user needs to know can be far more difficult, and understanding the equipment so that you can figure out how to map its properties to the users needs is also more difficult. In many cases, there are safety and regulatory considerations as well. And most writers -- people who identify themselves as writers, I mean -- don't have any experience with the task or the tools that these users are performing and usng. All this means it is more difficult to get into the position of really knowing what it is that the users needs to know.

Also, users in these fields often require specific training before they can use the machinery or perform the tasks, which means that the share much more of a background and vocabulary with each other than typical desktop software users do. All this means that it is easier of people coming from working in those fields to turn to doing technical writing in those fields. They are writing for people with tasks and backgrounds very similar to their own. Domain knowledge is therefore more crucial than writing skill.

Second, while the ideal qualifications of a tech writer are that they a) know how to write, b) understand the technology so they can talk to the developers, and c) understand the users and their tasks so they know what to write, the fact is that it is hard to find enough people with all three qualifications. People do therefore get hired for tech writing jobs with only one of two of these qualifications.

There are many in the field who insist that this is the natural proper state of things, that all a tech writer needs are good writing skills and the ability to do research. Many employers disagree, for the good reason that they have cost constraints and deadlines to meet and that tech writers researching things from scratch not only takes too much of the tech writer's time, it takes too much of everybody else's time as well.

In short: Technical communication is not a profession with fixed boundaries or expectations, much as some people and organizations would like it to be. Your mileage may vary.

posted over 7 years ago

CC BY-SA 4.0