Five predictions for technical communication in 2016 and beyond

It’s not quite 2016 yet, but here are our five predictions for technical communication in 2016 and beyond.

Please note:

Here are our predictions:

1. As documentation becomes to be seen more as part of product design, so the technical writing process will become part of the product development process

We’re likely to see reviews and version control follow the developers processes, and be managed via tools such as Git.

2. Markdown will break out from being an authoring format for developers and into the mainstream

Markdown offers separation of look and feel, variables, topic-based authoring and single sourcing, in a tools-neutral, simple to use, format. At a push, you can also do conditional publishing, too (information typing is lacking, though). Because it is used by developers themselves, we’re likely to see the tools develop at a rapid pace, and become more powerful and easier to use.

3.  More technical communicators will use Lean methods when working in an Agile environment

Lean is something we’ve been discussing for a number of years, and seems to have picked up as a new topic at conferences recently.

4. We’ll see greater use of the imperative voice in topic titles

We explored this earlier in the year – The decline of the gerund in technical documentation?

5. The popular Help authoring tools will be able to generate embedded Help and on-boarding screens

This is more a wish, but it wouldn’t surprise us if the Help authoring tools will enable authors to single-source Help text that will be embedded in the UI itself or appear within on-boarding screens.

Your predictions?

Do you agree? What you see as future trends? Use the Comments box to let us know.


Larry Kunz

I find #1 particularly interesting because some of the CCMS vendors are marketing “end-to-end solutions” that incorporate other functions beside content management — in particular, collaborating and reviewing. I wonder if there’s much of a market for this. In fact I haven’t encountered a single project where the developers have embraced a CCMS-based review process. It seems therefore that the CCMS vendors might do better if they stick to managing content and facilitating translation, and not worry about covering the whole documentation workflow. Would you agree?

Ellis Pratt

Good question. I’ve seen it work in Confluence, but that’s not a CCMS. If reviewing is done mostly by TechPubs, then maybe it should be in the CCMS. If it’s by developers, possibly not.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.