ClickHelp Technical Writing Blog
Stories for technical writers, web developers and web designers willing to grow

Good Technical Documentation: Users First, Lawyers Next

Posted by
Anastasia in Technical Writing on 8/27/20193 min read

hammer

We love technical writing, and, we like to think about it as something that can make the lives of so many people better and easier. We place readers on a pedestal and keep looking for ways to connect with them, to communicate more effectively. From our standpoint (as creators of a software documentation tool), the idea of helping users should be the primary concern of technical writers and be reflected in goal setting and planning.

But not everybody shares this point of view. Naturally, there is not just a single goal and perspective. And tech writers' attention is divided among them, which is totally fine. Besides just being helpful, doс teams need to think about stuff like decreasing the workload on the support team, adding SEO value, keeping up with sprints and product releases, etc.

These things are part of the deal, they are all important aspects of technical writing, and this is how technical writing defines itself as part of company business processes. But, sometimes, people sacrifice a lot of potential value for the sake of other things, and this is where they can be wrong.

Sue Me

law

Things start going south immediately when 'helping users' turns into 'protecting yourself from users'. This sounds delirious at first, but, as much as users drive your business, they can easily become your downfall. And, even if it's the market or competitors who do you harm, it is actually your own users who will pull the trigger by not buying your products or services anymore.

Aside from that, some companies figured out that user manuals are perfect for their legal team to shield the company from lawsuits. While it is obvious that technical documentation should grant protection from bad cases of product misuse that can lead to injuries or worse, some companies can't help but take it to the extreme.

When Being Proactive is Bad

doc-reader

Nobody likes getting sued, so companies tend to be proactive and super cautious about everything. Lawyers need to make sure every opportunity to protect their company is being considered. That's when they can really start pushing doc teams towards including more data pertaining to possible lawsuits.

You know that things are getting out of control when user manuals are not so much about helping customers anymore. Help topics become cluttered with information only some of which is even relevant for the overwhelming majority of readers. This definitely defeats the purpose of help authoring. Here's what happens:

  • Finding relevant information becomes a challenge for readers.
  • Topic structure suffers greatly from piles of warnings and notes.
  • Overall company image gets spoiled due to incomprehensible documentation.
  • More content means more time spent on its creation and further maintenance.

Technical documentation loses its sharpness, and that's probably the worst that can happen.

Conclusion

Don't fall victim of trying to be too cautious - the thing is, it is impossible to protect yourself from everything. Focus more on your readers and attend to their needs first of all. Consider what they should be warned about and keep it at that. No need to turn your user guides into a weapon the primary aim of which is shooting off ominous tentacles of delusory lawsuits. You are better than this.

Good luck with your technical writing!
ClickHelp Team
Author, host and deliver documentation across platforms and devices

 

HTML Templates for User Manuals
Download Free Templates

Want to become a better professional?

Get monthly digest on technical writing, UX and web design, overviews of useful free resources and much more.
Like this post? Share it with others:
×

Mind if we email you once a month?

Professionals never stop learning. Join thousands of experts subscribed to our blog to get tips, ideas and stories from us once per month.
Learn more on ClickHelp
×
By using this site, you agree to our Security Policy and Terms of Use.     Learn more