Picking the right format to publish your help files can be tricky, especially if you’re creating your first help manual and you want to avoid the biggest mistakes first time help manual authors make. The right format determines if your users have access to your help files exactly how and when they need it.
If you’re using a help authoring tool (and you should because they make it easier to write better help documents in half the time), publishing in multiple formats should be no trouble at all.
The big question we’re answering today is, should you publish a print manual (hard copy), or a screen manual (PDF, CHM, Web based HTML, eBook format...).

When you write a great help manual you do two things – help customers find and use appropriate solutions easily and slash your business customer support costs significantly.
Even more, customers will be glad to recommend your product, and leaders in your business niche will easily recommend your brand to other experts and their customers. This is why writing a great help manual is one of the best investment any business can make.
But how exactly can you write a great help manual?

There is only one rule for picking the best format for publishing help manuals: pick the format that makes the manual easily accessible for users when they need it and how they need it.
Interestingly, product users have access to several devices, software and digital content including web browsers, PDF, Microsoft Word and smart devices such as smartphones, tablets, Kindle, iPads, Macs... The list is almost endless. This is why writing a quality help manual may be the best investment your business make.
But with such a long list, what’s the best format for publishing your help manual? Let's review some of them.

What’s the worst mistake you can make as a first time help manual author?

A good help manual is user-friendly, and contains clear instructions that users can find and use easily. But if you’re a first time help manual author, creating a good one can be a tough task, especially if it’s your first technical writing project.
Interestingly, every great help manual writer had their first moment too, and made several mistakes on their first attempt. We’ve compiled these mistakes, so you wouldn’t repeat any of them. Thankfully, you can learn from these mistakes and create a top-notch help manual on your first attempt.

Let's face it, help documentation today has a terrible image. Almost everyone you talk to about it has a bad impression of help manuals. There are lots of different reasons for this, some of the most common are:

• It doesn't answer the questions you have
• You can't find the answer even though you know it's in there somewhere
• The manual is hard to navigate
• The documentation is out of date
• The documentation doesn't exist yet

Many authors of help manuals have discovered that help authoring tools or HAT software programs are a great way to quickly and easily write manuals, and other help documents. Not so many people stop and think about the way using HAT software programs actually benefits everyone else, including the product manufacturer paying for the manual, and the end user of the product.

Microsoft Word is a great piece of software. It allows users to quickly and easily write anything from a school report to business letter. The biggest advantage which Microsoft Word has is user-familiarity, it is a software which most of us have grown up with using it both at school and in the office. For many people it is still the natural choice when they need to write anything in a business environment. And for most purposes Microsoft Word is ideal, but there are some applications including writing product documentation for which it is not so well suited.
There are many reasons why Microsoft Word is not the right tool to help you write product documentation, here are just five of them.

Almost everyone has at least one help related horror story to tell. Whether it is about trying to understand a product when the help manual has been written in such poor English that it is unintelligible, or a product that has shipped with a manual for entirely the wrong model. Perhaps the story is about one of those manuals that are packed so full of details that there is too much information and it becomes almost impossible to find the answer you need quickly. There are many ways that help manuals can go wrong but in general they can usually be broken down into two main areas...

Writing a help manual can often be an intensely frustrating process. Everyone understands that the ultimate aim is to create a manual that helps your users solve their difficulties with your products and understand all their functions. The difficulty lies in working out how to get there. Most authors will have had the experience of staring at a blank piece of paper or screen, wondering how to start their latest book or article. When writing help documentation the main problem is deciding how to approach the subject.

Writing help documentation can be a tricky process. You need to learn to think like a product user not a developer. As the person responsible for writing the help documentation you may well have been involved with your product for a while, and have become very familiar with how it works. This is useful when writing help documentation but it can also be a disadvantage as you approach the product in a different way to those looking at it for the first time. What may be obvious to you may be a complete mystery to someone without your prior experience of the product, or knowledge of the design process.