Skip to Content Skip to Main Navigation

Rethinking the Technical Publications Process

23rd September 2014 Posted in Blog, Documentation 4 Comments


The process of book publishing is clearly a group effort. The book may start with the author, but to get it from the author to the end reader means it also has to go through a number of specialists, like an editor, copy editor, book designer, typesetter, printer and others before it ever lands on a bookshelf. So why is the parallel process used to output technical publications primarily the responsibility of one person?

Longtime corporate publications specialist Alan Porter points out that the book trade is based on the premise that the artistic elements, the creation of the content and the design of the book are only individual components of an overall modular process, and that by treating those components separately, the business of publishing flourishes because the process is scalable and repeatable.

In his article, >Why Technical Publishing Shouldn’t Be Art, Porter explains how, by separating each of the technical publications processes into separate modules, each handled by a specialist with the applicable tools, just like the book industry, we can streamline and even automate the business of technical publishing. For example, those with the strongest design or layout skills would apply those talents consistently across all deliverables, instead of having each technical communicator design, author, edit, layout, proofread, publish, etc. It’s not only a more efficient model of delivering tech pubs, it would seem to provide the ability to improve the consistency and quality of final deliverables. It seems to make a lot of sense to us.

Read Why Technical Publishing Shouldn’t Be Art and then leave a comment here with your thoughts. Do you think technical publishing would benefit from the modular process Porter suggests? We’d love to hear your opinions.

Please follow and like us:


  1. By Ashleyon 24th, September 2014 at 9:11 am

    This is spot on. It’s a great thing when a company creates a process for utilizing its technical communicators to their strengths. It actually helps the team operate at maximum production efficiency. Sadly, in the corporate environment, it is often more cost-effective to employ TCs who can do it all.

  2. By WAI_editoron 24th, September 2014 at 12:23 pm

    Agreed, Ashley. But it seems like some compromises could be made. For example, someone who was really good with page layout might be given more of those tasks and fewer unrelated tasks, while someone who was very good at writing procedures could to more of that. As long as there are more than two in the group, there will always be a disparity in skills. Of course, the idea doesn’t work in a lone writer situation.

  3. By Nicholas Wadeon 7th, February 2018 at 12:19 pm

    Whilst I can see merits in your philosophy, I just plain don’t agree, and I think it comes down to what you define as a writer.
    If a writer is simply that – writes words, then the writer is not an information communicator, because information is tied up with the layout, the graphics the…whatever. Reading documentation is a matter of appreciation for the eyes, not necessarily of facts.
    Sure, if you want a production line, you could have ‘the writer’ write and pass it through a conduit to the next phase. But we have structured writing environments which accomplish uniformity of content? And the page design is normally a company definition anyway? Graphics are a matter of understanding, and the illustrator understand his complex illustration software but would have to be educated on the product or topic to achieve a result that may still not convey the information that the author want to impart. I can’t see how you can suggest a dedicated ‘ page layout’ person – you have a company style after all, use the template.
    And yes, it is more economical to use a number of TCs who can do it all, because if you look at what they are doing, it is probably more than one manual at a time. Comments, reviews, etc do not follow a natural progressive process. An author/TC is so much more than just a function on a production line. Your model is very simplistic and ignores so many factors and assumes the author/TC is some simplistic device you just press the button to use.
    An author has to ‘understand’ the subject about which they are writing, It is not just about churning out API (which can be automated) but by emotionally putting themselves in the seat of the reader, what they need and feel. Graphics are not just about drawing an object, they are about supporting the information in the text.

  4. By Nicholas Wadeon 7th, February 2018 at 12:40 pm

    And, I’d like to say, that yes, it is bloody art being an author/TC. Any good author/TC takes a pile of rubbish information from uninterested sources and sculptures it into something magical. Do you honestly think that software developers talk in procedures or impart clear explanations? Do you think that when you have a meeting with an author and waffle away for an hour you really impart all the necessary information? In my experience, meetings are about 10/15% information, coupled with a lot of kowtowing, knee bending and a few facts. Not only that, but authors have to have some semblance of knowledge about the subject right? They have to know the subject and probably a few ancillary subjects as well that they just won’t ever use. A developer only has to know what he is developing in (okay, perhaps a little bit more but associated) but we have to understand not only writing but the range of technologies – whatever they might be. If we write about API, we have to know about Curl, Rest, Jason, Java TCP/IP blah..blah etc, even though we don’t use them every day or in fact any day (other than to create the docs). If we write about a technology, we have to learn about that technology, we have to overnight become experts with whatever the project members have been spending all day, every day for the last 6 months on, we have to know what they know and how to communicate it. Get real – get a Technical Author.

Leave a Reply