Technical Writing and Big Data

A recent discussion between a few members of the Tech-Tav team about how you can actually prove the “value” of technical documentation has got me thinking.

After discussing the value of data analytics to business and what return on investment really means, I realized that documentation is the center of a really significant Big Data issue that everyone seems to be talking about. I had been wondering why so many new companies were entering the relatively small documentation/help authoring space recently and why - with all of these new products to make our lives as tech writers easier - many people have been running in fear (and holding on to their Word documents even tighter than before).

For a long time, documentation was a separate business entity. Writers did magic things with Word files, Framemaker and In Design, and at the end, you had a document and then a book. Suddenly, you had PDFs with links and then help files came on the scene. All of this was still in the realm of technical writer magic. (Do you remember the days when you would produce a help file in less than three days and the developers would come back and practically throw candy at your feet??!!)

Development and documentation also suffered from a horrible separation, one might even have called it a divorce.

Suddenly, the world of social media changed our minds and our mindsets about what actually is important. “Connecting with customers” quickly became the sales buzz phrase of the decade. Everyone wanted to be heard, and we learned through social media that most people have scary/funny/outrageous ideas in their heads and, strangely enough, many of them involve cats. (I reserve the right to bog about cats and social media later).

We also learned that customers get vocal and they get angry and they talk to their friends and influence their decisions. All of these things were not surprising, and yet they seemed to surprise many traditional marketing and sales departments. Here is my absolute favorite "power of social media" thread of recent months. The sheer brilliance of the campaign is astounding:


Until the metrics of good customer support and the social media proofs of how far people will follow brands they love came to the forefront, most folks figured that it didn’t really matter if you had good or bad documentation; people bought and were loyal to products on the strength of the product itself. Documentation was an afterthought.

Today, we know those long-held buying and customer engagement theories to be false. People are loyal to brands that are loyal to their customers. Brands have developed new faces to their social interaction and to their previously impenetrable public facades.

A brand that does not respond on twitter or social media to a rant or a rave is quickly considered disconnected and out of touch, whereas generous actions on behalf of a company now build brand and self-market products when they go “viral”. In an age where the average high school student has 1000 friends on Facebook and the average college student might have upwards of 2500, the idea that bad support or customer care can or will be silenced or ignored is as ancient as fixed 9-5 EST hours for customer support.

Customers want smart products and smart solutions. The age of dumb support (books/pull information) is effectively over. I know, millions (ok, maybe 3 of you) will email me to tell me that the EU regulation 7657254.7866AbC requires that your product can only be released in Crete and Estonia with printed documentation and so PDF is all you need to do.

The EU may one day wake up, or they may not and they may keep forcing you to kill trees and print books needlessly for the next thousand years, but the point is that while the EU says PDF, your end customers are looking for their smart and integrated support/help and documentation.

They are demanding that products offer intelligent UI, easy to manipulate and understand HW, and user friendly support and integration. They demand that development and documentation get remarried and bury the hatchet of animosity and lack of communication of days gone by. In fact, they demand that documentation and customer support become synonymous. Why they were ever two departments is actually curious to me, but I digress.

Big Data is all about realizing who, what and where your customer needs you and answering those needs. If PDF answers those needs, run out and greet them with it at the door. But if they need more than that, be ready and able and capable of delivering what, when and where they need it. It might be social documentation, it might be smart search, it might be push help, it might be holograms.

Oh, I really hope it is holograms!


But let’s stop making the discussion about us writers and refocus the discussion on our users. They still need us. The perfect intuitive UI has still not been invented, and neither has the perfect iphone or gear or piece of hardware. Our sole purpose is to make the life/job/experience of the user of our product or service easier, less annoying, less cumbersome and more enjoyable.

There are so many tools at our disposal and so many opportunities to make what we do more effective and useful. It is an exciting time to be a technical writer, so let’s jump on the Big Data bandwagon and serve our customers better, help grow sales and bring value to our products.

Not every technical writer can give specific metrics about every repeat or up sell they bring to a product line or a service. They can, however, look to see how much customer support and engineering time is spent on answering customer issues and solving end-user problems. They can see how quickly support and documentation questions get answered on social media platforms and if customers are happy with the answers they received.

They can see how their documentation is appreciated or used via analytics and social media metrics. I have yet to see a company who got their documentation right, who focused on users and their needs, who delivered when and where their customers needed it and didn’t increase sales.

Maybe the argument is easy to make after all.