What does a technical writer do? This is a question asked not only by readers or beginners interested in the field, but by technical writers themselves. The Society for Technical Communication (STC) defines technical writing as
“simplifying the complex … technical writing involves communicating complex information to those who need it to accomplish some task or goal.”
In other words, technical writers meet readers’ needs by simplifying complex product information. But is technical writing just about effectively communicating product information?
The last time I ran a job search for technical writing opportunities in India, it yielded 1056 results! Some of the skills that I saw in the JDs included problem-solving skills, communication, writing API documentation, blogs, marketing articles along with internal-facing technical documents as well as project/program management, and research skills. All the skills amounted to one common point – one needs several different skills to succeed as a technical writer.
So what does a Technical writer really do? Here’s what I was able to decode from being a technical writer for the past year.
Helping with the User Experience
As technical writers at Whatfix, my team’s primary task is to create support documentation. But as we are the first users of the products, we also noticed many places where the UI copy could be much more clear. That’s when we realised we can make a huge difference!
We started providing a simple and intuitive UI Interface and copies for prompts, error messages or warning messages that customers may encounter. Our goal was to provide a friction-free UI so that end-users don’t need to refer to Support documentation.
First Users of the Product
Technical writers need to understand and empathise with customers. We not only make information consumable but try to reduce the effort to understand stuff – by building trust and reliability. We become the customer spokesperson as we are the first real users of the product. We understand the intent of the product and align it with customer needs, all the while providing product feedback from the end-user perspective.
As first users of the product, we at Whatfix are constantly trying to identify use cases that will help our end-users solve a problem. One such use case that we identified was on pages that had large flowcharts. It created a horizontal scroll bar that was a little inconvenient to use. The solution was simple – minimize the left navigation pane thus clearing up more space for the article to load completely without any scroll bars. To achieve this, we created an automated Smart Tip (using our product). When the user lands on an article, the Smart Tip clicks the minimize action to seamlessly increase the article visibility without breaking the readers’ flow. We also ensured that there was a tip that showed users how to maximize the left navigation in case they wanted to navigate to another article.
Creating videos and tutorials
It’s not enough to just create information. As tech writers we need to make sure that we use the correct medium so that the information is useful. Many users prefer watching a video snippet rather than having to read a lengthy document. We realised this and introduced a tutorial library on the landing page of our support site. Initially, we would use Amazon Polly for voiceovers, but we were constantly on the lookout for a better alternative that would sound even more human.
Most text to speech converters generate voiceovers that sound mechanical and lack a human touch. That’s when one of our PMs suggested an AI-based application that helps to generate speech that sounds exactly like a human. Amazon Polly got it right to a good extent but we still had to put the punctuation and pauses to get the correct tone and intonation.
The new tool that we used took care of these pauses, intonations, and pace. What was the only input that was required? Just text! Unlike in Polly where we had to type small paragraphs at a time and check the intonations and pauses, by providing punctuation, this application made our lives simpler as we just had to feed in the entire text (paragraphs together) and the output generated was phenomenal. It even enabled us to choose a person who appeared as an overlay on the video and even lip-sync with the generated voice! The final output saved us tons of time!
Besides, we have stopped hearing complaints about a mechanical voice!
Dogfooding your Product
The phrase Dogfooding your product, or eating the dog’s food (as a dog food manufacturer), is a widely adopted best practice in many industries. It refers to the practice of using your own products before you ask anyone else – including your customers – to use them. The technique of dogfooding becomes a tool to find usability issues and resolve bugs before your customers discover them. More than just reducing bugs from an application, the goal is to step into the customer’s shoes, understand their pain points, and empathize and resolve their struggles.
Here’s an interesting scenario where we came up with a use case for Help about help. And our users loved it.
Whatfix has optional features that need to be configured internally (by the Whatfix Support Team) before a customer can begin to use it. Often, our documentation content asks the customer to contact our support team to enable the configuration – as these configurations can only be done by our support or engineering teams.
But what if it is our support team that is looking at the article? How can we show additional information to our support team so that they don’t have to refer to multiple sources?
The platform that we use to author and publish content doesn’t provide this functionality. Besides, the documentation is not behind authentication. So it’s not possible to use the login information to show different content to different users. But we solved this problem like we solved most other problems at Whatfix. If you can think about it and explain the why – there’s usually someone around to help you figure out – how.
We realized that there was an easy workaround. And this we achieved by – dogfooding our product.
There’s a cross-functional team that dogfoods Whatfix on several internal applications. Typically, when you want to segment your content so that you can show specific content to specific users, you need to make sure the user is logged in to your support site. Then depending on who is logged in, different visibility rules are applied to contextually display content.
But the use case we implemented on our support site was different. We don’t require any login to view support content. So we had to figure out a way to show only internal users additional content.
We figured a way to identify internal users even if they were not logged into our support site. When they navigated to a support article and the support article had a configuration, they would see a small tip that gave them a link to the internal-only content.
Here’s how an article appears for different audiences.
Customers:
Employee:
To conclude, Technical writing is not tied to just being a support mechanism. By going above and beyond what a technical writer is traditionally expected to do, you can be an asset to the organization and help even help achieve product goals.