Steps to Creating Help

 Here is a quick 10 step overview to how I like to create End User documentation.

1. Analyze the needs of the users. It all starts here. Begin by asking what users want to do, their core tasks and responsibilities, and how the application assists them with these goals.
2. Make a list of the articles your users will need. This list of articles will include the instruction that you write. It does not need to be exhaustive as it is to get you started down the right path. As you begin creating the content, you have more ideas for more information that’s needed.
3. Get access to the product and explore it. Access to the development environments, test logins, bug tracking tools, and other related sites and assets to explore the product (usually a web application in IT) are invaluable to writing. You can then explore the application in terms of the list of articles you want to write. You may need to set up demos with developers
4. Start developing your help material. I like to write content in Google Docs because it’s so easy for my developer colleagues to review. The commenting features for Google Docs are unparalleled and allow lots of back and forth exchanges. But you could start writing anywhere. The key is not to get mired into structure and format at this stage. Just focus on the content
5. Review your content with subject matter experts. Ask the product manager which person will be the designated reviewer, and make sure to follow up with the person about his or her preferred method for review. If the person doesn’t get around to reviewing anything, consider setting up a meeting to review the content during the meeting
6. Figure out the formats you need to publish the content in. for example, If no one asks for a lengthy PDF document, don’t assume you need to provide one, particularly if your product is web-based and you’re in an agile environment. With agile, things change quickly so any PDF you create will be out of date. Eliminating the print deliverable can simplify publishing considerably. If people really need something printed, consider creating a printable quick reference sheet (1-3 pages on a specific task).
7. Select a publishing destination. There are many different destinations. What’s right for one situation may not be right for another. Different organizations use different methods. I keep my focus on the content.
8. Convert your help material from your scratch pad area (e.g., Google Docs) to your tools and publish the material. The conversion from the scratch pad writing tools to the formally published output will invariably introduce errors and other formatting issues that you’ll need to fix and address.
9. Create quick reference guides that pull out significant, overview-like material into a highly compressed guide. You could create a quick reference guide using something like Microsoft Word, or single-sourced perhaps from your help authoring tool. The main point with a quick reference guide is to be brief, basic, and visual.
10. If you need video tutorials, pull from your help material to create several 300-word scripts. You don’t need a ton of videos. They’re mostly introductory for new users, so cover the basics. I prefer Camtasia Studio as my video tool and publishing on Youtube or Vimeo. However it is also easy to attach them to the help site.

Why hire a Technical Writer

Many people in the software industry have great skills, and believe that they can write, however, a technical writer must possess superior grammar skills, advanced level word processing skills, and a keen awareness of the target audience. Technical writers produce documents the reader can understand and find the desired content in the document or online help. They also must have subject matter expertise and the ability to communicate effectively with the subject matter expert (SME).

Almost everyone owns a computer that contains some sort of word processing software. So why hire the services of a technical writer? Word processing software is only a tool. It's the person behind the tool that makes the difference. Here are some benefits of hiring a technical writer:

•  Technical writers bridge the gap between product designers and those who must use the product. We transform industry jargon into a language that all audiences (from novice through expert) can understand.
•  Well written documents reduce calls to your technical support department. Customers who learn how to complete their tasks by reading the documentation won't have to call your support staff.
•  Hiring a technical writer significantly reduces your documentation costs. Technical writers can write more concisely without sacrificing quality, resulting in shorter manuals and production costs.

In my career, I have seen thousands of dollars wasted by companies that use precious engineering time for writing manuals.
If your engineers give me the facts, I can sort out the data at a fraction of the cost!