How do you create effective technical documentation for a remote audience?

A simple rule to deliver effective technical documents is to answer the following three questions and then add further details as required- * WHAT (it is about) * WHY (it is required) * HOW (you can achieve XYZ) You can split long answers into sub-sections and use pointers to convey steps. Don't forget to include headings/ sub-headings for better navigation and understanding. There is no need to use jargon or complex words. Prefer to write as simple as you can in fewer words. Include related diagrams/ flowcharts/ screenshots for compelling documentation. With this formula, you can easily create your first draft. Later, you can add more information/statistics/examples to enhance the content.

While planning the document, you need to know the type of audience too. For eg., technical or general. If the group of audience is non-technical, your approach towards writing documentation can slightly differ. Also, it is good to have some engagements like surveys or direct documentation feedback.

Great point, and here is how I learned about my audience: - Personas: great for anticipating what the audience needs from your documentation. - Use case: a one-pager is different from a long-form user guide, and a SAAS product is used differently than a hardware product. Understanding the use cases gives you a goal post to move towards. - Feedback: feedback from existing and prospective users is extremely valuable and can be gathered from comments, a rating system, and from online forums.

These same issues can, and should, be used when designing the UI. All to often the menu items are cryptic to the end user. Just one more area where Product Managers are critical.

Technical writers in a way act as a standardising tool for a product. In terms of a SaaS product, where every stakeholder might be addressing a feature in their own familiar terms, it is often technical writers who gauge the popularity of each of them and decide what to name the feature. Most importantly, continue using the same terms across the relevant articles, or any related content. Another aspect to consider is "keep it simple". You don't know who is going to be benefited from your content. You are preparing yourself to serve all kinds of audience. Hence, keep it simple and be consistent!

This is a great piece of advice by incorporating different devices. In platforms, you’ll engage with your end-user, because you understand that they have various ways of learning. Keep the VARK model in mind and you’ll get it right more often.

VARK is great, but old school version is KIS - Keep It Simple. The older adage was keep it simple stupid - with stupid equating to no language beyond 5th grade. Whether your audience is remote or "local" less words, more examples-graphics-photos-video always helps. I don't believe "engaging" or "appealing" are what we are looking for. That is marketing. Tech doc is simple, easy, and does not require you to think (much). It simply steps you through the process to make something work for you.

The principles laid out in this article apply to any good technical documentation development (not just remote audiences). Totally agree that a good technical writer takes their documentation and uses it to validate its accuracy and usability, along with the additional vetting by SMEs, end users (if you have that luxury), etc. Reminds me of a quote from Bobby Weir, guitarist for one of my favorite bands, the Grateful Dead. He said something to the effect that, when evaluating their live performances, he always asked himself, did I enjoy it? Because, if we aren't enjoying our own music, how the heck can we expect our audience to be enjoying it? OK, we don't need the comments about the majorly transformed states of mind ... I'm just saying :)

I don’t know why the title put emphasis on “remote” audience. First, how do we define who falls into the category of remote audience? Pretty much most of the tech docs are for “remote”audiences. Second, if we really wanted to write an article about how to write tech docs for “remote” audiences, then this article didn’t address any specific approaches for the “remote” audiences.

Don't forget to answer the question "Why?". Though certain things are instinctive to the writer, the reader likely does not have the same set of experiences and knowledge so they may not know why certain steps, materials, or processes are important or necessary. Knowing why is also empowering for the reader. It will draw the reader in to pay more attention and gain more comprehension from the documentation thus increasing the documentation's effectiveness.

I am not sure we need to put `for a remote audience` in the title. All the 6 points listed in this article did not mention anything about this `remote` audience.