The Difference Between a Solid Technical Writer and an Irreplacable Expert
Forging You Into an Exceptional Technical Writer
What separates a solid technical writer from one who is truly irreplaceable?
If you’ve ever wondered why some writers are respected across teams while others are just “good enough”, you’re in the right place.
How do I know? I have interviewed, coached, and led dozens of technical writers for over a decade.
Today’s article is your invitation to join this exclusive club of excellent technical writers.
Last week, I showed you how to lay your skill foundation as a technical writer.
But communication skills, research techniques, XML, CCMS, and the ability to structure user-centric documents are only the starting point.
Today, we climb the next level of your evolution.
Task-oriented Documentation
The first special skill on my list is one many technical writers claim to understand - yet, they often don’t apply it.
Writing user documentation based on the tasks of the users.
Novice technical writers make the mistake of documenting what they see. Expert technical writers document what the users will ask themselves.
An example to make my point:
A developer hands you a ticket on which he describes a new feature: A wizard that allows the users to import project data.
A novice technical writer will create a new section titled “Using the Import Wizard”.
The problem is that the user will never use these words to look for that section - for one simple reason: the user doesn’t know that the software handles imports through wizards.
Instead, the users will ask themselves: “How do I import my project data?”. So a more fitting section title that will lead to better search results in a user manual would be “Importing project data”.
Do not make the mistake of blindly describing features. Put yourself in the shoes of the reader. How would somebody who isn’t developing the product search for specific information?
If you introduce instructional sections with weak, generic verbs like “using …” or “handling…”, chances are high that you describe the software instead of answering a user’s question.
Aliby Usability vs. Holistic User Assistance
Eventually, every technical writer will run into this situation.
Product Manager: Hey Andreas!
Andreas: Hi, Mr. Product Manager!
Product Manager: Guess what? We found a bug. Can you describe the workaround in the user manual, please?
A novice technical writer will follow the request like a direct command. An expert technical writer will deny the request, explaining that it could lead to serious legal consequences for the company.
If users get hurt or damage property (data loss counts as property damage, too), and the user files charges, the court will analyze the situation.
The court will identify that your software product had a bug that led to the product’s misuse.
“But wait, our documentation describes how to avoid the problem!”
That may be true, but that is not a state-of-the-art option for resolving the risk of misuse. The manufacturer is obligated to deliver safe products.
To do so they must:
Make sure that the product is inherently safe.
This means that the software is designed to make misuse as impossible as possible.
If that is not technically possible, the manufacturer must plan safety measures to contain the damage.
An example from the context of machines: If you build a table saw, you can’t cover up the blade 100 %. But you can add sensors that register fingers and initiate an emergency stop.If both steps 1 and 2 are not technically possible, then - and only then - is it sufficient to only warn the user in the user manual.
In that particular order!
Your PMs might not be thrilled about your response, but I am sure they will appreciate your protecting them from a sales ban or hefty lawsuits.
Remember, user documentation is not an excuse for poor usability!
Improving Translations and Making Them Cheaper
While usability and clarity are crucial, technical writers can dramatically cut costs and improve the quality of translated documentation.
Expert technical writers are masters in writing text that reduces the risk of mistranslations and saves a fortune on translation costs.
The former is easily explained. Technical writers are trained to engineer their text for comprehensibility. That means, among others:
No synonyms
No ambiguous language
Absolute consistency
You must eliminate the risk of misinterpretation for the reader. By that, you also reduce the risk of misunderstandings for the translator.
The other part of translation-friendly writing lies in understanding how translators translate text.
They do so by using Translation Management Systems, short TMS. Examples of such tools are SDL Trados, MemoQ, or Across.
A TMS is a tool that aids translators in translating text more efficiently. Simply speaking, every translated sentence is stored in a database along with its source language. The database is called the Translation Memory.
When a translator starts another project and encounters the same sentence, the TMS automatically translates it based on the previous translation.
The TMS also shows the translator, if a similar sentence has already been translated before, e.g. 85 % of the sentence might be identical with a previously translated one. It displays the former sentence with the deviation.
The translator sees what changed and doesn’t have to translate everything from scratch. This feature is called fuzzy matching.
Translation agencies offer discounts based on fuzzy matching rates. For example: 100 % matches cost only 5 % of the full rate. 90 % matches may only cost 50 %. The rates depend on the agency, but the message is clear. The more consistently your documents are written, the more money you will save.
This quickly adds up to a little fortune and is a great benefit of having a technical writer do the actual writing!
Mastering these skills will put you on a new level and set you apart from most technical writers I have met.
For those of you who support me through a paid membership, I have prepared another bonus skill that is often overlooked.
When utilized correctly, it will significantly improve the quality and cost-efficiency of your documentation while minimizing your efforts.
Keep reading with a 7-day free trial
Subscribe to A Linguist's Tech Conquest to keep reading this post and get 7 days of free access to the full post archives.