The technologies of Information 4.0 mark the beginning of the end of technical communication as it has existed since the early 1980s. That won’t happen overnight; many companies still use PDF, which was introduced in 1990, and Microsoft WinHelp, officially replaced by HTML-based help in 1997. But the changes are becoming visible.
In this third and final post in our primer on Information 4.0, guest author and techcomm expert Neil Perlin outlines some of the wider industry changes – and what technical communication professionals will have to do to step up.
1. Adapt to new methodologies, standards and technologies
These may be entirely new – or new to today’s technical communication – but technical communicators should be able to use some of them, such as metadata, after a short learning period because of similarities between metadata and content creation. Many of the changes that lie ahead build on a lot of the skills that technical communicators already possess.
Other more technical technologies, such as AI, machine-created content and RDF (Resource Description Framework from the Worldwide Web Consortium), will be more of a challenge and involve retraining. (If demand is large enough, vendors may release authoring tools that hide much of the complexity and open up the market. This has happened in the past: before GUI tools like RoboHelp appeared, online help coding was done by literally a dozen help authors across North America. Four years later, after the GUI tools appeared, I was giving presentations attended by 100 people from the Boston area alone.)
Still other technologies and standards, such as iiRDS (International Standard for Intelligent Information Request and Delivery), are so new that no training is available as of the date of writing. Authors who want to learn it as early adopters will have to do so on their own.
What this means: Greater technical skill, driven by non-stop professional education, is vital.
2. Rigorous project management
Projects will be large, complex and rapidly evolving, and will need standards, best practices and governance to be defined, promulgated and enforced. Without this, projects will easily go out of control.
What this means: Formal project standards and management are vital – no more ‘winging it’.
3. Greater involvement with issues traditionally left to IT
Many engineers and managers still think of our output as those printed user guides that no one reads. But the advent of online help long ago took our output beyond that. XHTML-based online content is as much software as it is text. That means there may be issues involved in creating and distributing it that engineers and managers aren’t aware of. We have to argue those issues – and that calls for the ability, knowledge and confidence to do so.
What this means: We don’t have to be programmers but we must be able to argue our own technical issues.
4. Customer contact for better contextualisation
If contextualisation is a core part of Information 4.0, technical communicators will need to define and understand users’ contexts in order to create either the content or the rules for machine-created content. Engineering could do this for us but it means that our knowledge of contextualisation would be second-hand and engineering might not realise the need for certain kinds of detail. Contact with users would solve this problem but a common complaint from technical communicators is that “we’re not allowed to talk to the users”.
That’s going to require cultural change within our companies to drive recognition of the benefit of technical communication and the need to support it. Getting there means promoting the idea that user documentation isn’t just “those manuals no one reads”. Instead, good documentation helps sell products by adding or reinforcing an air of quality, retain existing customers by helping them use your products, reduce support calls and thus supports costs, and by being open to the future.
What this means: Technical communicators will need a business-level view in order to justify access to customers.
5. Ability to make the business case
Technical communication needs to defend itself from being seen as a cost center and to put the case for being seen as a strategic centre for content, especially when it comes to Information 4.0 technologies.
Budgets are tight and techcomm is often controlled by decisions made in other departments, such as marketing or sales. For example, many online content authors have to use style sheets created by marketing whose settings don’t apply to technical communication, or decisions about a CMS are made by sales, without input from technical communication. Those situations make sense if technical communication is seen as a cost center.
To escape this trap, technical communicators have to show our benefit in business terms. We have to present statistics showing how documentation has cut support costs or increased customer satisfaction and retention. And we have to present that data in business terms.
There’s also an Information 4.0 aspect to this. In the past, companies would buy several copies of an authoring tool like FrameMaker or Flare, perhaps send someone to a training class, and that was it for expenses. But the technologies of Information 4.0 will be new, will require new tools and training for the proper use of those tools, analyses of strategic direction, analyses of legacy content and the conversion of some of that content to new formats, and other expensive tasks. This will complicate technical communication’s making the case to management that: a) Information 4.0 is worth the investment, and b) that technical communication should drive the Information 4.0 effort or at least be a major participant.
To do so, technical communicators must learn the language and concepts of business. Some technical communicators have a business background (I have an MBA in accounting and operations management myself) but too many of us don’t have that background and look askance at it. That has to change in order for us to converse as equals with management and to compete with external consultants.
What this means: Giving technical communicators a business-level view to let us understand and demonstrate our importance to the company.
Our future in Information 4.0
The word-processing revolution that began around 1981 changed technical communication. The online help revolution in the early 1990s changed technical communication even more so. So did the move to HTML in 1997. In each case, technical communication became more powerful, more flexible and more ‘technical’.
Information 4.0 will continue this trajectory, involving us in delivery mechanisms and technologies that are barely on the technical communication horizon today. It will be a time of turmoil as older technical communicators leave the field but also a time of opportunity for new communicators, and for those who enjoy technical change and intellectual challenge.
Image: (CC) Pixabay
Neil Perlin has 39 years’ experience in technical communication. He is the founder of Hyper/Word Services, which provides training, consulting and development for online formats and tools, and is the author of eight books on computing – his latest, Writing Effective Online Content Project Specifications, was released in January 2018. Neil has been a columnist for STC and IEEE and is a popular conference speaker, recently at TCUK 2015 (keynote) and TCUK 2017. He founded and ran the Bleeding Edge stem at the STC Summit, and was STC’s representative to the W3C from 2002 to 2005. He is a Fellow of the STC. You can contact him at nperlin@nperlin.cnc.net or on LinkedIn, Facebook and Twitter (@NeilEric).
