Contemplating Help

I’ve been working on a fairly major help project over the past few weeks. In the process, I’ve been thinking a lot about how we, as tech writers, write help and what users need from help.

I was first introduced to help authoring 12 years ago while completing my degree in technical writing. Like most tech writers, I learned about books, topics, indexes, keywords, and the other components of help files. I also learned the best practices of help authoring, including breaking information into small, self-contained chunks, keeping information types separate, and focusing on user tasks rather than software features. Although HTML-based authoring tools and outputs were available at the time, publishing help on the web was still a novel idea.

After graduating, I began creating help systems in the real world. Often, this meant porting the content from a product’s printed user guide to an online platform (HTML Help, HTML, PDF, etc.) with few, if any, structural changes. This was my primary work flow for many years. And I suspect it was the primary work flow of other tech writers as well.

While we worked on user guides and help, our users’ world changed dramatically. Internet access became nearly ubiquitous in the developed world. Google made searching the web faster and easier. Blogs, wikis, and YouTube made user-generated content a reality.

What does this all mean for help? Is it even relevant in a world where users can simply search the web for thousands of free resources when they have a question or encounter a problem with their software products? I think help can still be relevant. In fact, it needs to be relevant to engage our users and allow them to fully realize the value of their tools and technology. But this requires us, as tech writers, to move beyond the basic lessons that I learned in college over a decade ago:

• As Jakob Nielsen and others remind us, web users will simply move on to the next website if they can’t find the information they need. Web users are also help users. Therefore, more than ever, we need to ensure help is task-oriented and easy to navigate.
• Simply porting content from user guides is no longer satisfactory. We need to create and structure content for help. This doesn’t mean that we can’t use single sourcing tools to create both types of deliverables, but we need to use these tools more wisely.
• We need to move help content online and ensure it’s accessible to search engines and social bookmarking tools. That said, we need to provide at least some help offline as well for times and places where web access isn’t available.
• We need to engage our users, even allowing them to contribute to content where appropriate.
• We need to keep content current, responding to any trends we see in support calls, user forums, etc.
• In the spirit of the web, we need to think of help as part of a network of user assistance tools that includes Knowledge Bases, learning management systems, user forums, wikis, and so on. Help can even be a portal to these other resources, connecting users to information they may not have even know was available online.

Many of you are already following these practices. Please share your experiences with us.

More…

Marketing and Tech Writers

In a recent post on his blog, Neil Perlin noted that business and financial knowledge is critical to the success of tech writers. This is particularly true for tech writers working by themselves or in small teams who need to justify the hiring of new writers or the purchase of new software.

Marketing is an area of business that many tech writers, myself included, don’t fully understand or appreciate. That’s why I found this video of Seth Godin from the 2008 Business of Software conference interesting. While Godin’s talk is geared towards software developers, it has implications for tech writers as well.

More…