I entered the field of TechComm in 1980 as a junior tech writer and have had the good fortune to enjoy a career spanning over four decades. I’ve had different job titles, worked for (and with) different companies, used different software, and performed different tasks. Yet throughout it all, I’ve remained under the broad umbrella of technical communication.
As you can imagine, I’ve seen a lot of changes. The profession has morphed and redefined itself several times. Here are some of the changes I’ve seen, as well as my prediction about continued evolution.
Some of these stories may sound incredible to today’s younger practitioners; However, I am confident that many of our more “seasoned” practitioners will recognize some of these changes and trends.
Technophobic English majors: In the 1980s, it wasn’t unusual for a “tech writer” to be an English major (or worse, an English Literature major) with absolutely no technical skills or knowledge. I remember writers who were frustrated novelists or university professors. They wrote heavy, pompous prose that served no purpose other than to show off their vocabulary. They were often so technically clueless that they handwrote text to be typed (and typeset) by someone else. I remember one gentleman who quit in a huff when asked to use a word processor.
The geek squad: At the other end of the spectrum, those of us who were not technophobes had to be massive geeks. Early DTP was performed with embedded codes (troff and nroff) – a far cry from the nice WYSIWYG applications that exist today. If you wanted to change the typeface or font size, you needed to embed a command. I recall spending five hours trying to debug a table that was not printing correctly. TechComm professionals who used these UNIX-based formatting codes were made of sterner stuff. We were also early users of email systems, long before any friendly GUI applications opened up the Internet for mere mortals. As all of this predated the WWW (World Wide Web), only true geeks had access to the Internet.
The blind leading the blind: It was not uncommon for someone to write the documentation without access to the actual product. Unskilled tech writers took content written by SMEs and “fixed” it. This resulted in a lot of horrible documentation, thick with vague, inconsistent, feature-based descriptions of the product, rather than clear task-based topics. If you asked a writer if they had used the product themselves to verify the information, they would look at you as if you had just landed from another planet.
Analog tools: If you never used a box knife and a light table to create graphics, you don’t know what you are missing. (I’m kidding… it was horrible.) Light tables (for our younger readers) were large angled worktops with a light source underneath. They were designed to allow you to trace objects or layer pieces for a final physical graphic, which then had to be physically pasted onto the master mock-ups. Printing was offset; we took physical printed pages to the print shop. We then received printers' proofs to check before the final print run was generated. By today’s standards, it was tedious and inefficient. I don’t miss the lengthy process, and I am grateful for the elegance of press-ready PDFs for digital printing. Nevertheless, I feel slightly nostalgic for the sights, sounds, and even smells of an old-fashioned offset print shop. It was noisy and dirty and industrial, but it had a soul.
Specialists and dilettantes: Writers wrote. That’s it. Very few had the skills or knowledge to consider the document design. In the days before advanced DTP applications, layout was often done by graphic artists. As they had no understanding of UX or usability, or even good design principles (as they relate to readability), content was presented with filled and justified margins, multiple line spacing within paragraphs, and other violations of good content design.
The user is always wrong: Users played almost no role in documentation development; their needs were not considered. Documentation was something that had to be done, but it was only for other geeks. Average users were expected to be trained; almost no product was intended to be self-explanatory from the documentation. This attitude made it very difficult to talk about UX with clients.
I am delighted that most of these old mindsets have now died out.
But what are we seeing now and where will our profession take us in the future?
One of the most challenging aspects of any technology field is what I call the elasticity of development. When new tools, technologies, and practices are introduced, the old ones do not automatically disappear. If you think of this as a ruler with old techniques on the left and new on the right, you have new developments being added faster than the old ones drop off. The ruler, in effect, is being stretched. The gap between advanced best practices and outdated techniques grows wider with each passing year. You can still find companies doing documentation in Word, sometimes without templates. Forget single sourcing and content reuse! Forget writing global-ready content! Forget minimalist and user-centric design! While forward-thinking companies leap ahead with the latest tools, many companies remain in the dark ages of TechComm.
While this elasticity is not going to disappear, I think that the following trends will dominate over the next decade.
A writer for all content: The old “silo” approach of distinguishing between MarCom and TechComm content has started to disappear, and I suspect that trend will accelerate. People do not distinguish the source of content; to most people, everything they read or see from a company, whether it is intended for presales information or post-sales instruction, is simply “company X” info. Why should it be inconsistent in tone, style, and terminology? Today’s TechComm professionals must be able to write content for all phases of the customer interaction. Content needs to be seamless. This doesn’t mean that we can ignore the purpose of any piece of content; but we must bring our understanding of user needs to every aspect of UX content.
The Jack-of-all-trades: Good TechComm professionals have always been able to embrace different skills and knowledge areas, even when the majority of our peers were specialists. This will intensify. We need to understand human factors such as psychology, learning patterns, and social or environmental influences. We need to be open to cross-disciplinary education to prepare us for this field. That includes knowledge of development and UI design, marketing, risk analysis, and more. We shouldn’t fear venturing into other areas; that is part of what makes this a rich and endlessly stimulating profession.
The commodity: The reverse side of the Jack-of-all-trades is the low-paid writer who is a bulk commodity. We have seen this over the past 20 years as companies offshore their Tech Pub departments in an attempt to save money. The writers are poorly skilled and unable to see the big picture, let alone push back when ordered to write illogical or unhelpful content. Sadly, I fear that this trend will continue.
The further deterioration of language: Proper grammar, syntax, and punctuation have taken a beating in the past decade, and not just among laypeople. I see “professional” TechComm writers making sloppy mistakes all the time. Even professionals already working in the field have – at best – a sketchy grasp of grammar. Any professional writer should have a high level of knowledge and accuracy with language, but that is not the case. Social media has had a profound effect in numbing our sensibilities over dreadful mistakes.
Warring standards: Globally accepted standards in TechComm will remain elusive. Worse, many standards, developed without the input from true professionals in the field, will be adopted in some countries. TechComm practitioners will be forced to write to standards that may be counterproductive to UX. I suspect that this will get worse before it is resolved (if at all).
Tool fragmentation: If you think that there are too many DTPs, too many HATs, too many graphic tools, too many video editing suites, too many CCMSs,… I have some bad news. The problem is only going to get worse. In an already crowded market, we will see more applications and more companies getting involved. This means that a good TechComm professional will never be able to “know” all the tools; they will have to be a tech-savvy person who understands the broader concepts for a category of tools and can learn a new one quickly.
Our profession has changed so much over the past four decades. In many ways, the work is almost unrecognizable. But at the core, our role remains the same: to provide content solutions that help both the users and our clients. How we get that done may change, but our mission of creating clear content that allows people to use a product safely and effectively should always be our north star
Do you have a story about the Old Days of TechComm to share? Let us know!