Technical Writing is Technical Training
“Technical Writing is Technical Training” is probably the summary of my technical communication career.
I know my trainer friends will object to this statement but I’ll say it again all the same: “Technical writing is technical training.”
Then I’ll add: “It’s the training of a special type.” Or at least it should be.
If by “training” you only mean standing up in front of a group of people, making a PowerPoint presentation, and then making sure they’ve learned what you were trying to give to them, then yes, technical writing is not training. In that special and limited case, training uses materials provided by technical writing to come up with the correct presentation for the specific audience in question.
But a more liberal definition of “training” definitely does cover technical writing because if the ultimate goal of technical writing is not “training” in its most generic sense, then what good is it? And audience as factor is just as relevant in technical writing as in technical training.
Wikipedia defines training as “the acquisition of knowledge, skills, and competencies as a result of the teaching of vocational or practical skills and knowledge that relate to specific useful competencies.” There is nothing in that definition that leaves technical writing out.
The whole idea in writing a user manual, for example, is to make sure the user acquires the “knowledge, skills, and competencies” to use the product in question. However, tech writers try to accomplish that goal not by standing in front of a group of people but by creating “documents” that can be read either in print or online and in the privacy of the end user. In that sense every reader/listener/viewer of a technical document is a classroom-of-one, a customized classroom in which one can sit while wearing pajamas, thus offering the most relaxed “training environment” possible.
The traditional definition of “training” leaves out an increasingly important and expanding world of “knowledge, skills, and competency acquisition”: online training and e-learning. That’s where the relevance of technical writing becomes even more apparent since, even when one relies heavily on videos, the traditional in-classroom issues specific to in-class training become suddenly redundant irrelevant; issues like “know-it-all” students, or “can-you-please-repeat-that-again” participants etc. that have been addressed in Yehoshua Paul’s seminal blog post: “Multiple and Emerging Roles in Technical Communication: Training.”
There is no need to pose a “turf war” of sorts between technical writers and trainers since not only they need to rely on each other by benefiting from each other’s best practices, but they also increasingly need to deliver what the other is delivering for maximum end-user benefit.
What good are excellent training skills that rely on poorly written and designed product documents?
Conversely, what good are detailed user manuals if they are not assessing and evaluating what and how much of the material is learned and retained by the readers/students/users?
Technical writing and training are like the two wings of the same bird, the bird of user performance. If both wings do not flap at the same time in harmony, the users will run in circles and get lost in meaningless details.
As a writer coming from the documentation side, I’m trying to learn all I can about training techniques and try to make assessment and evaluation a part of my regular documentation – even though I do not hold a class in front of a group of users. There are plenty indications that this will result in documents that will benefit our customers more. I’m 100% sure of that.
“Training has specific goals of improving one’s capability, capacity, and performance,” says Wikipedia. If that’s also not the ultimate goal of all technical writing, I don’t know what is.
