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.