Seven myths about Technical Communication

Technical Communication is multifaceted and includes cross-functional spheres of activity and advances various skills. Its extreme versatility offers a safe spot for people to get confused. I, as a Technical Communicator, often get asked some strange questions about my job, and it makes me think that we need more clarity at this point. In this article, I invite you to dispel several widespread myths about Technical Communication and get closer to the reality of the job from my standpoint, obviously.

They say Technical Communication cannot have a voice and style. It must be objective.

Any type of writing, video, or visualization has its tone of voice. Not to mention the style. Depending on the audience and their needs, tone of voice helps quickly grasp the meaning of your content because it is consistent, distinct, and speaks their language, has their vibe too. Whenever people deal with your product, it almost talks to them through UI labels, messages, and support content. So, it’s rather each product has its own voice, and all content in any form we may choose — it is aligned with how product sounds to its audience.

For example, if you create content for non-technical people, it will be inappropriate to communicate with them through the developers’ language. And depending on your goal or user’s pain that you are trying to solve, your content can sound, for example, carefully guiding them through complicated tasks, or energetically announcing them the option that they have with your product, let’s say, to boost their productivity.

With a defined tone of voice, you avoid any possible ambiguity and build trust with users.

They also say that Technical Communication is only about writing or “this random task is not my job”.

If you think that Technical Communicators spend most of their time writing, you may be mistaken. As we don’t write our plain ideas from our minds, it’s vital to investigate, communicate, analyze, gather information first, and only then write. You may also need to do design, quality assurance, or some management work related to content work.

At the same time, we have another misleading statement — a professional Technical Communicator must be a subject-matter expert in all technical fields like business operations, modern technology, manufacturing, or healthcare.

Of course, you should know your product for content creation, and it would be your competitive advantage if you specialize in one domain. Still, it is not obligatory to understand all technical nuances or to be able to explain, say, taxation specifics of a certain country because you will most likely and should have dedicated subject matter experts and reviewers.

I’ve been told that Technical Communicators have nothing to do with user experience.

We are customers’ advocates. Moreover, every part of the product has its own effect on users, content included.

I mean, that user’s feedback is essential for you to fit your content to user’s convenience. So, if you are not allowed to contact users directly, try to get their feedback through the product manager or customer support representatives to identify customers’ needs and pains.

Another trick, which also affects the ease of use, is to collect customers’ vocabulary. Imagine the situation where you use product-specific terms in one way while customers use them in a completely different fashion. If you have interviews and thoroughly research the main usability patterns, nothing can stop you from building a successful product.

Beginners into Technical Communication go like “I should start with writing. The rest will come along”.

Not always. Starting with the strategy, having a bigger picture of what should be your end result, and design rather than writing is a good point. Otherwise, if you do it in the reverse order, you may have problems with the documentation structure, relevance, and usability. Abandoning the whole picture at the beginning usually causes major corrections or changes to the entire content idea and the selection of its form. And time spent on a task only increases.

In addition, the strategy presents a single vision. Working without all teams being on the same page causes discordance in actions. Discordance in actions entails discrepant content to be delivered and visible to the outer world, damaging the product’s reputation.

Writing without design is like cooking a dish for the first time without a recipe. If it is simple enough, you can prepare it. If the dish is Soufflé, I bet it is better not to give it a try without the recipe.

There is no room for innovations and experiments in Technical Communication.

There are things you have always done in a specific way. There are things you have never done in any way. You may stick to how you got used and do tons of manual work in updating or publishing processes, but the world is rapidly changing and is here for you to explore it. Thus, do not be afraid to challenge your status quo and see how you could make use of new approaches or tools. Remember that automating things could save you 20 mins to start with, but having it as a habit, you will save much more time and efforts later and will be working smart! My point is — be innovative, track market trends, and voice your ideas for improvements. If not you solve the puzzle of how to improve a certain publishing process, someone in your team will definitely have an idea. A little automation never hurt nobody.

The documentation is not part of the product. No one reads the manuals.

This is a common one and a tough one. Understanding the value of documentation, not only by Technical Communicators but also by the product management team, is another key to product success:

• Time saving. Your customers look through the website with help articles and quickly find all they need. If the docs have been done right, obviously.
• Time saving again and onboarding simplification. When product knowledge is stored properly, way fewer developers will be bothered with newcomers’ questions about how things work. And here, you save yourself a risk of losing essential information that is kept in a head of just one person on the project.
• Customer satisfaction rate and budget increase. They gain satisfying experience and do not want to research other variants or buy those goods at competitors’ websites.
• Customer support time reduce. They see the Contact Us form but do not reach out to the customer support team because they can simply find the information on the website.
• Quality and process control. This way, your team members can improve their performance by speeding up development cycles, reducing rework caused by misunderstandings, and eliminating risks associated with miscommunication.

Excuse me, but it is your fault!

The last part with which it is worth finalizing the article is — do not blame your customers for using the product incorrectly or misunderstanding a thing. Concisely and clearly explaining concepts, workflows, and steps helps break the ice. But what if the product is designed to be complex and puzzling? Maybe it is your turn to advocate and simplify complex setups in design and product vision?

To sum up, every experience is unique and requires a unique approach, but the rule of thumb is common — think about the users.

Be passionate about what you do. Good luck on your Technical Communication journey!