David Farbey wrote a semi-existentialist post on the challenges for technical communicators yesterday. I’d like to look at the issue in a different way, by looking at the big questions in technical communication today. The answers to these questions (which may be decided by people outside of the profession) are likely to affect the future direction for technical communicators.
What is the value of technical documentation?
Technical communicators have traditionally suffered from not knowing how many people have benefited from the “products” they’ve delivered. Today, with Web-based content, it’s possible to know how many customers you’ve have had today – how many people have read or downloaded the content. We can track the correlation between the technical documentation and the support calls. We can see which sections of a video-walkthrough users are skipping.
Yet very few Technical Authors or Documentation Managers do this. Where content strategists measure, learn and improve their content iteratively, Technical Authors seem blindly confident they are producing great content users need.
In times of limited budgets, it’s vital technical communicators are able to demonstrate the value of what they create.
Technical communication best practice was established over 25 years ago; is it still valid?
One of the topics we cover in our advanced technical writing course is that many of the leading Web companies don’t follow technical writing best practice. We now live in a world where technology is part of our daily lives, and where we’ve seen new practices emerge in the ways organisations sell and market their products. Perhaps it’s time to test whether technical writing best practice needs to change as well.
What is the best approach to creating user documentation when working in an Agile environment?
Agile programming methods provide challenges for technical communicators. They can end up with little time to write the documentation before the release date, and they can struggle to acquire the information they need for developing the information.
We’ve seen a number of technical publications departments move away from working one sprint behind the development sprints. We’ve recommended using Lean methodologies, and this is an approach some documentation teams have taken. At the MadWorld 2014 conference, a number of the delegates said they had moved to SaFe (Scaled Agile Framework).
Agile should force development teams to ask, do we need user assistance, and how much is needed? There are Epic Value Statements for the software, and there should be Epic Value Statements for the user documentation.
Will we move towards design-led user assistance?
Organisations such as Alfresco, Citrix and IBM are moving towards a more design-led approach to user assistance. They are moving away from the idea that technical communication is merely about creating a Help file or a PDF at the end of the project. Citrix and Red Gate Software have made the Technical Authors responsible for all of the words on the User Interface, and Alfresco is embedding more and more help text into the application screens themselves.
This design-led approach moves technical documentation towards the front of the development process, rather than the end. It will be interesting to see if this approach is adopted more widely.
Who should write the content?
Typically, Technical Authors have been assigned the role of creating user documentation, and have used specialist software tools that non-professionals have found difficult to pick up and use.
Some organisations have moved to wiki-like tools that are simple enough for anybody in the organisation to use. We’ve also seen the rise in popularity of user generated content, which can be located in forums, comments at the bottom of a page, video walkthroughs, blogs and other locations.
So we need to ask, who should be writing the content? The role of the technical communicator could become more of an editorial and managerial role, with some of the writing delegated to users or other staff members.
Please note, I use the word “some”. One of the most common reactions from non-professional technical communicators is that writing and organising good content is really hard! Their appreciation of the task often goes up.
Can we get organisations to move away from Microsoft Word?
What big questions in technical communication have we missed? Share your thoughts below.