Predictions for technical communication in 2017 and beyond

Our predictions for 2017 are…the same as they were for 2016! Having said that, there are a few adjustments we can make to the comments we made last year. Below, you’ll see our 2016 predictions In italics and some thoughts for 2017:

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.

This trend now has a name: “documentation as code” (or “docs like code”). This is partly a reaction to more projects following the Agile methodology, with fast and frequent releases and a team-based approach to projects.

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

Markdown is now used for documenting some Cloud applications at IBM, so it’s gaining some well-known users now. We’re likely to see further developments with Cloud-based collaborative authoring tools (such as Corilla, Forestry and CraftCMS). We may also see more use of markup languages that have semantic capabilities as well, such as AsciiDoc.

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

It’s still early days for Lean in technical communication, but at last week’s “Agile the Docs” conference, we did see an example of how Lean had been used by Worldpay to identify where there were bottlenecks and waste in their writing process.

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

This continues to be a trend.

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

This was more a wish, and it didn’t happen. We also hoped for Markdown support, but that also didn’t come to pass. The popular authoring tools have added more support for Git and similar tools, and working collaboratively in the Cloud. They have improved.

What trends do you predict for 2017?


Larry Kunz

Nice post, Ellis, and congrats on having done such a good job with your 2016 predictions. That puts you miles ahead of most other pundits.

Now, a question for you: Which trend would you most like to see for technical communication in 2017 — regardless of whether or not you think it’s likely to happen?

Ellis Pratt

Which trend would you most like to see for technical communication in 2017 — regardless of whether or not you think it’s likely to happen?

One I didn’t mention – that documentation is planned for at the beginning of any project, rather than at the end.

Fergal McGrath

Ellis, I agree with most of the predictions above but “The popular Help authoring tools will be able to generate embedded Help and on-boarding screens.” intrigues me, especially for embedded help. I imagine that embedded user assistance usually needs to reside in resource files. On the issue of Markdown support, as you probably know, Markdown support was recently added to Oxygen XML Editor. I’m not sure that MadCap or Adobe or Microsoft have any incentive to add Markdown support to any of their authoring and publishing tools.

Ellis Pratt

Thanks Fergal. The HATs are getting better a dealing with distributed source files, so there would be check in/out of such files.

Leave a Reply

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