Whether you’re an aspiring technical writer or a seasoned one, you should know that everyone in this line of work experiences challenges from time to time.
Last-minute product changes, uncooperative subject matter experts, and more—factors like these can reduce the motivation for writing and slow down the process.
If this sounds familiar, let us show you that these challenges aren’t a reason for switching careers.
Instead, you can use them as opportunities to improve your writing practices and even introduce company-wide improvements to technical content creation.
Changes to the Product Made Last Minute
Last-minute changes to the product affect all team members in the production, including technical writers.
While you can’t eliminate those changes altogether, there are still ways you can handle them. Let’s see what these are.
A Reddit thread about the best and worst things about being a technical writer has revealed that most writers struggle with seemingly small product changes that have a massive impact on technical documentation.
Unfortunately, both freelance and in-house technical writers experience the same difficulties with last-minute changes.
For instance, here’s an excerpt from the list of factors that writers in TechWhirl, a technical communications company, find stressful.
Note that although the list comes from a “classics” article, the described challenges coincide with those from the recently updated Reddit thread.
In other words, you can expect last-minute product changes regardless of where in the technical writing industry you work.
David Benovsky, who has worked as a technical writer at Kentico for over ten years, claims that participating in progress review meetings can help you manage changes and new features.
“When discussing new features and planning your team’s future work, try to think of related edge cases and ‘gotchas’ that were documented in the past, but many people will have forgotten about.”
Benovsky also advises using review meetings as opportunities to ask the production team questions about changes that could affect the documentation.
That way, you can shorten the amount of time you need to update documentation.
Another way you can minimize the impact of changes is by staying prepared. You can do this by practicing consistency in technical writing.
If you persistently apply the same writing principles, you’ll be able to go straight to updating documentation whenever changes occur and skip decisions regarding paragraph length and other stylistic choices.
According to MacBobby Chibuzor, blockchain developer and technical writer, there are several elements to writing consistently.
You can see the overview of the elements in the following image and find more details in the author’s blog post.
All in all, technical writing sometimes requires you to work at the eleventh hour.
However, you can stay in control of last-minute changes by having a reliable writing procedure in place and getting involved in the production process.
Unsuitable Tools for a Specific Project
You could be the best technical writer out there, and your work would still not be able to shine through if you had to use unsuitable tools.
Because of this, it’s vital to identify the best tools for each project.
The internet is full of horror stories about using outdated technology in software development.
This blog post, for example, calls Visual Basic a zombie language that has faded into nothingness.
As a tech writer, you’ve probably encountered clients insisting on exclusively using Microsoft Word for writing and had to explain that there were far better tools for technical writing.
Outdated tools aren’t the only challenge here. Sometimes, a tool is simply not compatible with the type of documentation you’re working on.
For instance, you won’t use the same image editing tools when writing an assembly manual and creating software documentation.
So, how can you find the right tool for your needs?
Since technical writing calls for teamwork between contributors, editors, and subject matter experts (SMEs), your writing tool should allow you to collaborate with other team members.
Archbee, our product documentation platform, facilitates collaboration with the system of inline comments, links, and mentions.
The tool lets you leave interactive comments within documents, which is a feature you won’t find in most traditional writing tools.
Archbee is also an excellent tool for software documentation because it doubles as a publishing platform. What does this mean for clients?
Let’s break down the technical writing process and find out.
With Archbee, the following takes place on a single platform:
- Technical writers write content
- SMEs review the content
- Managers publish the documentation
- Readers access the content
So, why use multiple platforms when one can do? And if you need additional tools, Archbee’s integrations eliminate any potential formatting issues.
To sum up, inadequate tools will slow you down and make technical writing harder than it needs to be.
Therefore, the first step in your writing process should be identifying the right writing tool with features suitable for your specific product or project.
A bit of time that you invest in researching the best resources and tools will help you write better documentation more effectively.
Lack of Information About Product Users
You can’t excel at technical writing unless you know exactly who you’re writing for.
You can overcome the challenge of the unclear audience by identifying the users of your product documentation and adjusting the writing style accordingly.
The reason why companies hire technical writers is not because they know the most about the subject.
If that was the case, they could just ask the lead engineers to write and simplify the process.
Instead, technical writers are there to translate convoluted technical information into content that end-users can understand.
They essentially translate information into knowledge, as demonstrated in the following illustration created by Onhike.
As the image shows, you need to vary formats, writing styles, and levels of technicality based on your audience.
For instance, if you’re writing documentation for end-users, you could include an overview of the terms used in the product.
Here’s an excellent example from the wiki of TalkChief, a business phone system.
The wiki, which was built with Archbee, includes a glossary of terms readers need to understand to use the product.
A straightforward clarification system like this one ensures that all users can interpret the instructions laid out in the documentation.
On the other hand, if you’re writing API documentation intended for senior developers, you’ll achieve greater levels of clarity by using the terms such as ECMAScriptwithout explanations that could clutter the content.
Determining the target audience will also help you define the amount of jargon appropriate for the technical documentation you’re writing.
You can use specialized tools to see whether the text is suitable for particular audiences, such as De-Jargonizer.
Tools like this one help you replace potentially confusing words with more appropriate ones.
However, you can only deal with different writing styles if you know who your audience is.
Because of that, you should sit down with the development team before you start writing.
Ask the team for a quick meeting where you’ll discuss whether the documentation is intended for experts or end-users.
A clear writing direction will let you deliver quality work that provides readers with relevant, valuable information.
Getting to Update or Rewrite Someone Else’s Documentation
Just like developers often complain about working with legacy code, technical writers find it challenging to work on documentation that somebody else has started.
Even if you have no problem updating documentation to reflect the current state of the product, there’s the challenge of matching the previous writer’s structure and style.
Luckily, style guides and document templates can do wonders for ensuring the consistency of technical documentation, regardless of the number of authors.
For the section about working on someone else’s documentation, we’ll turn to advice provided by Ugur Akinci, an expert technical writer whose contributions to Quora have more than 1.7 million views.
If you’re tasked with updating existing documentation, your safest bet is to follow the standards the previous author has set.
This task gets easier if all contributors follow the same writing guidelines, as Akinci recommends.
There’s no need to compose your internal style guide—you can use some of the already established ones, such as Apple’s, Google’s, or Microsoft’s.
When it comes to rewriting parts of the documentation, you should pay special attention to the writing elements that weren’t done with the style guide pointers in mind.
For instance, you should avoid writing in first person if the original author referred to the reader with you.
So, guidelines will provide you with direction in writing, but you should still watch out for inconsistencies from other authors.
Akinci also advocates structured authoring as a way to achieve content uniformity.
Structured authoring boils down to organizing documents in a consistent form regarding the layout.
A simple way to accomplish this is by using templates. Here’s an example of what the feature can look like in Archbee, our documentation platform.
As you can see, templates let all contributors follow the same document structure without having to analyze the previous documents manually.
With templates, you can avoid the challenges associated with continuing work on documentation written by multiple authors.
All in all, having the opportunity to start documentation from scratch is great, but chances are you’ll have to update the existing documentation at some point.
However, the right approach to document creation will help you maintain or even improve the quality of content.
Cooperating With Subject-Matter Experts
No technical document is complete without the SME seal of approval.
However, getting input from busy SMEs can be a challenge, which is why you have to be mindful when timing your inquiries.
SMEs are almost always occupied with work.
Whether your SME is a research scientist, a software developer, or a hardware engineer, they usually prioritize their primary work over documentation reviews.
In fact, many technical writers find cooperating with SMEs the biggest challenge in their jobs, as you can see in the Reddit thread we’ve mentioned earlier.
Seeing that you most likely can’t count on your SME to review each sentence as you write, you have to make use of the time you get with them.
A good starting point would be to schedule a meeting with the SME at the start of the project.
You can treat the meeting as an interview with the SME where you ask them specific questions about the product.
You can maximize the effectiveness of the meeting with thorough preparation, as advised by Kesi Parker, an experienced technical writer.
Rather than expecting the SME to guide you through the product, you should take a proactive approach and create a list of questions you’ll ask about the product.
You should also be ready to go off the script and ask follow-up questions about relevant parts of the product that crop up in conversation.
Parker also suggests preparing note-taking equipment, such as a notebook or a phone.
Taking real-time notes will provide you with a list of accurate vocabulary you can use later during the writing process.
The correct use of jargon will also reduce the time that the SME spends editing the documentation.
Lastly, you’ll be able to improve the collaboration with the SME by remaining equally meticulous in your review requests down the line.
If you encounter any areas you’re not entirely sure about during writing, you should leave comments that let the SME know which parts of the documentation they should zero in on.
All things considered, SMEs are just people trying to do their jobs.
If you need them to stop work and participate in technical writing, make sure you prepare to-the-point questions they can answer quickly.
Conclusion
In the process of technical writing, you’re bound to encounter challenges and even occasionally make mistakes. You shouldn’t worry, though—these experiences are fairly common.
More importantly, you can overcome the challenges with preparation and the right choice of tools you use to write and collaborate with other people working on the product.
So, before you start your next technical writing project, make sure you lay out the right groundwork. Your future self will be grateful!
