We all have heard a lot about the challenges faced by technical writers. A lot has been written and discussed. There are books and courses where this subject has been discussed in detail. As a practitioner and someone who is practicing technical writing for 30+ years, I would like to share a few challenges that technical writers face at their workplaces.
The first challenge is the technology used for creating and publishing content. The second is the technology that you may be writing about. And there are many more… keep reading.
Creating content using technology
During the olden days, technical writers had to give handwritten notes to typists who will then type in the inputs to create a document. But this arrangement was unsatisfactory and technical writers had to use the typewriters themselves to get the document right.
Then, computers and printers happened. The primitive Macs and dot-matrix printers happened and it felt like a great invention.
In the early 90s all technical writers were expected to know FrameMaker. They had to keep themselves updated with the latest versions. Then XML happened and the major push towards Structured Authoring or DITA began. The objective of Structured Authoring was to create chunks of content and maintain a shared repository, so that the chunks of content can be repurposed and reused in multiple ways.
In the fast-paced technology world continuing education on the part of technical writer is critical. Employers need to help technical writers up skill. In cases, when you are acquiring tool skills SMEs also need to give their consent for the same. In some companies’ engineers and experts too are involved in creating content. For example, if the content is created using FrameMaker and SMEs don’t have a license to use it or don’t wish to learn it – then learning FrameMaker may not help. Also, not all companies or workplaces need anything that complicated. I have seen companies investing a lot of money in tools only to drop it after realizing that nobody was going to use that. Most companies used the good old MS Word and it worked well for them.
Thus, the technology used to create content depending on the company and various other factors stated above is one of the general challenges faced by a technical writer.
Understanding the technology
The next biggie is having an adequate understanding of the subject matter that you are writing about. The degree to which you are expected to know the subject will vary from one job to another.
In some companies, the SMEs create the basic draft and the technical writers ensure it makes sense, the content is not redundant and formatted well. I cannot imagine working as a technical writer and not knowing the subject pretty well what you are writing,
I have worked with different employers and it has been a challenge to keep with the various subjects that my employers were writing about. The subjects have been varied and I found the exposure to explore these subjects interesting. That, plus the satisfaction of producing a document that reads well explains me having kept at the same kind of work all these years.
Interacting and dealing with SMEs
Interaction with SMEs may be a big challenge at times. They need to understand the value you bring to the process, which means they need to cooperate as you seek to understand their objectives and they need to allow you time to do your part.
Life becomes difficult when they don’t understand that meeting deadlines can be a serious challenge and consume most of the available time before providing inputs, review comments, and so on.
More often than not subject-matter experts lack any background or experience in help authoring. So, the information they provide has to be re-worked in many ways. Subject-matter experts often just give you data without considering how knowledgeable (or not) users are.
That’s why, for a help topic to make sense to readers, technical writers go above and beyond to restructure, simplify and provide explanations and references.
Not knowing what they want
Working out what the company actually wants and needs is a huge one. The company almost never knows what they want. It’s up to the Technical Writer to show them something achievable and then tweak it to fit their requirement.
Working with software
Working with what you’ve got. We are talking about software. It is no secret that the bigger a company is the more sluggish the process of approving and buying software gets. Oftentimes, you have to work with what you’ve got at least for the time being.
Creating something out of nothing
You are supposed to document how something works but there is not enough information about the subject to write a comprehensive guide. You would be expected to dig out your own investigation, information digging, and fact-checking.
You might need to chase down SMEs and stakeholders to interview them which takes time and finesse.Not having enough information to begin to write or update an existing document is a common challenge in technical writing
Involving and improving performance
I believe the most important aspect to improving performance as a technical writer is to become immersed and involved in the projects that you will be creating documentation for.
Becoming involved in the development process as early as possible provides a clearer definition of deliverables and how the user will interact with them.
Meetings or writing?
Seriously though, how do you skip all these meetings?
They all seem so important…
Here, developers will be talking about new functionality, and there we have testers pushing some changes that will most likely affect our documentation plan.
Meetings inside the documentation team happen on a regular basis and you can’t just forget about the all-company meetings that are important as well.
Balancing the complex and simple
Trying to maintain the balance between technical jargon and simple instruction is the one of the primary objectives of any technical writer. Technical writing must be technical, it’s in the name. But, that is not the way end users may need it. It is the technical writer’s duty to understand the subject matter and explain the complex in a simpler way to the audience.
Often is the case that the audience is unknown and therefore it must be assumed to include a broad range of users with varying levels of technical knowledge and background. Help documentation needs to be written in a way that can be understood by a wide spectrum of users yet communicates the technical details of the subject matter efficiently.
Being specific
Documentation needs to be kept concise and specific if it is to make the biggest impact to a user’s experience of a product.
It is unlikely that the first step for a new user is to examine the whole suite of documentation before they use a product, it is most common for a user to read the documentation if they have encountered an issue. When they have an issue, it is likely that they want to fix it quickly and therefore documentation must eliminate any uncertainty and ambiguity if the user is to have a happy experience.
Detailing the details
How “granular” your technical writing should be?
How much detail should you include in your writing?
How much is enough for your audience?
Should you describe every button and link on the GUI? Or
should you just write a troubleshooting guide at the highest level, and not insult the intelligence of your audience by reminding them to click the OK button on every screen after they are done?
Details is a common issue that is solved the better you get to know your target audience.
Never ending reviews
Sometimes reviewing a tech document takes longer than writing it. Either the reviewers are not available or they take too long to respond. Sometimes the review goes into a spiral mode. The reviewer is never satisfied and you are asked to do three, four, five drafts and have no idea when the task will be done. This is another common problem in technical writing.
Uncooperative SME’s would be the hardest problem to overcome. You need to be very good at drawing information from reluctant and busy people.
Getting a consensus on a work method can be quite difficult. Especially within a company where internal politics or personal conflicts make people unwilling to comprise or agree on a particular procedure.
Building and rebuilding your building
You start to write for product A but soon they tell you A is now B.
Just soon after you make a route correction and start to document product B, the news arrives: B will now be released as C.
So you go back to the drawing board, retake all the screenshots, change all chapter headings, re-do your TOC and Index, change the footers, etc. and start to rebuild your building.
That also happens from time to time in technical writing.
Remaining anonymous and upholding order
No one usually knows that you are a technical writer, since none of your guides or manuals will not include your names. It’s very rare in my experience for a technical writer to publish anything with their names.
You make good money for sure, especially compared to the poor poets, journalists and screenwriters. But at the end of a long career, no one will know how hard you fought to hold back the chaos and uphold order in the information universe.
If that kind of anonymity bothers you, you should probably choose another line or work.
No struggle. No progress. No success– Maxrime Lagace