Why Does Technical Writing Fail? 4 Reasons

Lying supine on the bedroom floor, exhausted, and while spinning an Allen wrench between my thumb and forefinger, I glance at the nearby waste bin into which I consigned my dresser’s instruction manual. Wiping sweat from my brow, I consider retrieving it from the waste bin, marking it up in red ink, and mailing it back to the manufacturer. I’d assembled the dresser without reading the instructions: not because it was simple for me (I’m terrible at assembling furniture), but because the instructions were useless, seemingly written as if documentation was nothing more than a checkbox for the customer. While this poor form didn’t prevent me from accomplishing my objective, I certainly would’ve been less sweaty and saved 45 minutes of my life had the dresser been shipped to me with documentation that technical writing used to accomplish so easily: documentation that simplified user experiences. 

While the advancement of any trade depends on how well the people who work in it adapt to and create necessary changes in the occupation’s framework, the willingness to adapt doesn’t guarantee successful adaptation. There’s oftentimes an incongruity between how we choose to adapt, and what the most effective adaptation requires. Unfortunately, technical writing is an industry in which many well-intentioned attempts to adapt to an increasingly fast-paced environment have misled the industry as a whole, including how its importance is perceived. If left unchecked, this will render technical writing obsolete within 20 years, and at the expense of the marketplace’s ability to adopt and proliferate important products. 

Technical writing (sometimes referred to as technical communication) used to be the process of distilling otherwise complex information into simple, precise, thorough, and actionable terms via written mediums like user manuals, instructional documents, and other highly specialized communication tools. As this definition implies, technical writing and communication spans a breadth of important purposes and industries. Now, however, technical writing is becoming a mere checkbox on new product release checklists. Even more troubling is the fact that the ways in which the trade has unraveled in recent years aren’t native to specific enclaves of any given industry. 

1. Products Are Tested, But Documentation Isn’t

This step is skipped so frequently and causes problems in so many user manuals because if it was practiced, it’d be the last step before product launch, and that’s where impatience creeps in. This is an understandable mistake given the increasingly fast-paced and hypercompetitive nature of the product release arms race, particularly in software. 

This occurs because an increasing number of brands have the chutzpah to believe they’re capable of Apple’s product marketing excellence. Somehow, and without the proper forethought that great technical writing produces, the product’s intuitiveness will transcend any need for explanation. The customer will automatically understand it as well as the engineer, so why fret the instructions? Because technical writing begins with a much humbler premise than delusions of product marketing grandeur, and that purpose is to verify the product’s functionality, and consequently, its limitations.

Technical documentation would fare much better with more testing specific only to the written instructions itself. Do brilliantly-designed products that reduce the scope and demand for clear documentation exist? Yes, absolutely. The problem is they’re a profound minority, and striving to follow in these exemplars’ footsteps is neither the way to a smart branding strategy, nor sufficient reason to jettison fidelity to old-school albeit effective technical writing practices.

However, a more forgivable cause of the phenomenon in which product development outpaces the rate at which documentation adequately supports it, is the genuine desire to out innovate the competition, with a faster speed to market. As tempting as this rationale may be (and easy to mistake for sheer laziness), a product is never ready for release to the public just because engineering has tested it. Yes, engineers are usually the smartest people in any room, but they’re generally less skilled in the qualitative components of outlining, testing, and managing quality assurance for product launches while maintaining an ability to think critically about their product’s users who, compared to them, are non-specialists. 

You’ll want to call in a sample size of at least 10 people (who are preferably like your target customer) yet unfamiliar with the product, to try using it, assembling it, or otherwise leveraging it based on nothing but the accompanying technical documentation alone. If even as few as 2 reasonable people become stuck or don’t see the value of the product itself, you’ll want to ask them why, and revisit the drawing board as needed. If they’re merely stuck, the documentation needs revision. If they don’t see the value, the entire product itself may need revision.

It may seem trivial, but  at market scale, the results of your findings are significant. If 2 people become stuck trying to use your product, or don’t see value in the product after using it, these 2 people become 200,000 in post product release sales to 1 million users. If you think that won’t impact your bottom line, you’ll see otherwise once word of mouth travels exponentially fast and negatively, and at the expense of your bottom line, reputation, and ability to sell future products. 

2. Errors of Omission Are Commonplace

Accounting for what should be in a technical document is far more exhausting than putting it into words. This, among many reasons, is why all technical writers want to be engineers, but no engineers want to be technical writers.

Much like Occam’s razor, which posits that the best theory is the simplest one, the best sentence (at least in technical writing) is usually also the simplest one. The lone caveat is that this is true only if the sentence doesn’t omit any necessary details. 

The result? Errors of omission. The engineer thinks deductively, whereas the technical writer thinks linearly. In fact, it can be said that the entire purpose of all technical documentation is to parse what’s deductive to an expert into what’s linear to the non-specialist. Otherwise, when technical writing and engineering collide, the ‘formula’ or ‘solution’ to the end user equation is provided without context or direction, which needlessly causes a fundamental disbelief in the value of the technical writing trade on both sides of the register. 

This problem not only perpetuates poor documentation, it also undermines the explanatory power of audience understanding as it pertains to your product. Given the extent to which technical writers increasingly work with engineers, and how frequently each of these worker’s skills are perceived to blend into each other, the problem persists in a lack of accurately updated documentation, head-scratching ‘pause points’ in new documentation, and even major errors in product development itself.  

3. Static Visual and Pictographic Overemphasis

Thankfully, user manuals haven’t become what the film Idiocracy predicted they’d become. Then again, were not trending in the right direction, and the 2006 film took place in 2505, so only 483 years of time will tell. 

Photo credit: Sci-Fi Interfaces

While Atlassian reports that 65 percent of the population are visual learners, pictographic information shouldn’t be relied on too heavily throughout technical documentation. The remaining 35 percent of readers may be so confused by what’s written that they choose to write a negative review, unsubscribe from your cloud-based software, or persuade others to avoid using what you’ve already sold to them.

Sometime between the novelist Thomas Pynchon’s tenure at Boeing as a technical writer and the proliferation of his complex works of postmodern fiction, use of visual explanations felt easier and comforting to those tasked with the technical ‘writing’ trade. As illiterate as our Idiocracy has become, however, graphic designers still need wordsmiths as much as wordsmiths still need graphic designers.

However, this isn’t just a visual-writing continuum: there’s still room for any other form of instructional content, be it video, audio, or any other medium best tailored to ensuring a customer’s understanding of your product.

4. It’s Assumed that Any Writer Can Write Technical Documents

While there’s a widely acknowledged gradation of technicality under which specific types of ‘technical’ writing can be classified, writers aren’t split into clear, corresponding technical equivalencies, and the industry’s certification entities aren’t helping. For example, a training manual for an inside sales department is instructional, and would therefore be considered ‘technical’ writing in some capacity. However, other variables aside, nobody would assume an inside sales training manual is more technically demanding to write than a 100-page user manual for a quarter-million-dollar B2B quality management system. Sure, there are markers like ‘Technical Writer I’ and ‘Technical Writer II.’ However, these simple classifications vary widely in definition from employer to employer and contract to contract.

Even the Society for Technical Communication, which is considered to be the foremost industry authority on technical writing certifications and resources, neither clarifies the skills and responsibilities necessary in various technical writing roles based on industry-adopted technical writing job titles, nor thoroughly defines the extent to which writers are capable of filling these roles successfully. True technical writing talent (unlike WordWoven’s) is usually expensive, and for good reason: it requires an increasingly rare skill set that most writers simply don’t have, and this phenomenon warrants more clearly defined standards in each technical writer’s aptitude. 

Moreover, falling prey to this paradigm causes plenty of low-paid labor that looks great on the accounting books and as confusing as the Unabomber’s Montana log cabin cipher to your customer. The only significant commonality between technical writing and other types of writing is that they involve putting words to a page. Everything else is almost completely different when it comes to technical writing.

While some technical writers can cross over into copywriting projects and therefore be hired to fulfill either function from the technical writing position outward, it’s almost always poor practice to allow bloggers, content writers, or copywriters without relevant experience to write technical documentation without requisite experience or some sort of technical writing accreditation (despite the latter credential’s imprecision).

This is also the case because most other forms of business writing are geared toward priming the top of a sales funnel (i.e., copywriting, blogging, and content writing), whereas technical writing retains the existing customer by enhancing their experience. This can involve, but is not necessarily limited to ensuring that customers re-enter the sales funnel, draw others into the sales funnel, and help turn the reader into a net promoter of the product or service. While these factors have ancillary effects on sales, they’re still significant.