The last podcast I recorded, on "Make Your Help Indispensable, Safeguard Your Job," with Mike Hughes, was so full of good information about how to make your help more valuable and user-friendly that I couldn't help but write up notes on it. Here's a list of the ten things I learned from my last podcast:
Users spend about 30 seconds on a help topic, so keep it short and get right to the point. On the other hand, try to cover as many of the problems users encounter as possible.
Avoid the trap of trying to provide "complete" instructions that don't address problems users will likely have. Long introductions, tables of buttons, menu explanations, and other information not directly focused on the context of users' problems will lead to unnecessary information glut.
Users need help in the application, so that's where the help should appear, not in a separate training system. When you separate learning from work, users are less likely to stop work and turn to another system to learn. The tasks they do and the help for those tasks should be integrated in the same user interface.
Research about how people use help often specifically prompts them into a help file, but the natural tendency, without these prompts, is for users to ignore the help altogether.
If you can figure something out on your own, so too can the users. Let your help focus on the true problems that users will encounter. Look for points of paint and information gaps on each page. Ask yourself, where am I getting stuck? Where will users get stuck?
An empty search results set is a perfect place to include links to help, such as FAQs or top problems, because users are specifically looking for help content. Many times help authors neglect this space.
Users are more apt to read quick reference guides than marketing material. If you need to get a product message across, it might find more readership embedded in the quick reference guide.
Help links and buttons are practically invisible to the user. But if you phrase your help as short questions in the interface, users are more likely to click them. When you do this, be selective about how frequently you implement the question links.
This is the fourth podcast I've recorded that's a "double-ender technique," where both the interviewee and I record individually on each of our machines in Audacity and then I overlay and sync the two tracks. I've found that almost everyone seems to have a microphone and doesn't have trouble recording in Audacity. Previously, I'd assumed this technique required too much from the interviewee.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here.