10 Things I Learned from My Last Podcast
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:
1. Make your help a mile wide and thirty seconds deep.
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.
2. Don't document everything. Instead, focus on the context of the user's problems.
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.
3. Put help where users perform tasks.
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.
4. The research about the usability of help is that people don't use help.
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.
5. Avoid obvious instructions.
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?
6. Search results are a great opportunity to include help.
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.
7. Quick reference guides are read more than marketing material.
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.
8. Phrase help links as short questions in the interface.
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.
9. Tools and technologies can distract you from what matters most: the content.
10. Almost everyone has a microphone for their computer.
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.
I'd Rather Be Writing Newsletter
Get new posts delivered straight to your inbox.
About Tom Johnson
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.