Why Help Suck (2 of 2)

It doesn’t really matter why exactly help system has become inefficient (if it ever were efficient). That fact by itself is not that important unless we do something about it. If you’re developing software and you’re considering developing a help system for your product. Here are some Does and Don’ts that could help you.

• Use screen casts instead of how-to guides: important part of any help system is the how-to guide (step-by-step description of how to do a specific task). Screen casts are videos capturing the user’s (in this case, the tutor’s) behavior on screen while performing a task. Videos are way cooler than how-to guides, and they’re not that hard to produce. Those videos have to be described in text in a way that would make it easy for the user to find a video using search.* Focus on search: the problem with categorization is that no two people can ever agree on how to categorize any content. No matter how organized and simple your categorization might be, it will always be hard for some people to follow because they’re not aware of all the content and that’s why they don’t understand why would you put this topic under this category not that one. Search goes around all that hassle by directly jumping to what’s related to the user’s input. You can optimize your content for search by adding the different forms of questions that might be asked about each topic. This way when users asks those questions, they can find them and hence their answers. You might as well tell the users that it’s okey to ask their questions in plain English because they don’t really expect that.* Use search engines to index your help system: since search should be the central focus of the start page of any help system, if you’re using an online help system you might as well use a search engine as your primary search engine to search your help system. All major search engines offer powerful tools to use their search as the primary search for any web site.* Offer categories as alternative: the Office 2007 Ribbon is one of the best things ever, but some people just didn’t like it. Don’t do the same mistake as Microsoft and drop categorization completely and only relay on search (they dropped menus and toolbars completely and only relied on the ribbon). Two reasons: some users might not know exactly what they’re looking for, browsing can help them. Other users use the topics related to the result of their search to find out more information about the software (Related topics. that sound like another thing you can do).* Offer related topics: some users use help to learn about the software, it’s a very hands-on approach. On the side of each page (not necessarily on the side, it could be up and down as well), make a list of the topics that are related to the topic is being displayed sorted by their relativity to the displayed topic. You could also create another section similar to the idea of “People who browsed this, also browsed..”. Offer a list of the topic that are not directly related to this topic but can be linked to it.
• Avoid endless hierarchies: categories should have a limited number of levels. Avoid having 20 levels of subcategories that will never guide a user to their destination, it will only drive them mad.
• Avoid confusing titles: while browsing your content, topics titles are not only representing the content of that topic, they are pretty much the topic. No one we’ll go through a topic unless it’s exactly what he’s looking for and if the title is not clear enough to speak for the topic, no one will read it. If the titles of your pages doesn’t seem clear enough for the average user, modify them or make it clear that you’re applying some naming conventions and list their meanings.
• Audience-Sensitive content: wouldn’t it be great if my help system can speak to me? And I don’t mean “speak” as in the act of talking, but more like as in using a language that I can understand. One major problem with help systems is that the content is used according to the concept “one size fits all”. If you’re looking for a piece of information, it’s there; you just have to find it. And finding that piece of information isn’t just about finding what page it’s on. It’s also about finding in what part of the page it is. Average users find themselves scrolling through pages of details on how a file is being streamed as binary before it’s transmitted over the TCP/IP protocol and how it’s being… zzz. Power users find themselves scrolling through pages of introductions on how to create a new file and a description of the Open File window. An audience sensitive content would offer different forms of the same content depending on the level of user’s proficiency determined by the user. Users are promoted to select their level of proficiency in the software and other topics that are related to the software. For example, a user that has experience in the previous version of the software doesn’t need to know about how features work; he only needs to know about the differences between the two versions. This kind of content can be developed by carefully tagging each paragraph of the content and just hiding and showing those paragraphs depending on the user’s preferences.

All this is great (I’m sure you agree ;) ), but is it really what you want? Do you want your help system to be efficient enough that users can actually learn and solve their problems without contact your support line or attending your courses? Maybe it’s not, but that’s another story.