I discovered an interesting post from one of the technical writing blogs I follow during my Sunday morning blog catch-up. Technical communicator Shweta Hardikar recently wrote a blog post pondering “embedded help” or, helping users solve problems without calling it help.
Although programs are constantly evolving and taking advantage of multimodal interaction, one important question remains: “how do I use this program?” Users want immediate results, they don’t like to read through 50-page user manuals and guides. Looking up answers takes the user outside of the program experience, ruining the immersion. And honestly, how many people actually bother to read or even keep the user manuals that come with programs? Although companies are getting smarter (and eco-friendly) with user manuals by storing them in the program or on a CD, the fundamental problem of having to go outside the program remains.
That is where embedded help comes in. Embedded help integrates the help directly into the application instead of through an outside source. This often takes the form of text that appears directly on the application, or via an easily accessed button. Not sure what a particular option does? Instead of making the user look up that bulky/poorly accessible user manual, offer a button labeled “help” or “?” if you don’t like the idea of using the word help.
Not every section of a program requires embedded help. Indeed, the golden rule of maintaining simplicity should remain in effect. The key behind using embedded help lies in anticipating where the user might have a question. A handy accessibility rule for programs and vital for web navigation, especially if you are running a business.
When I create product pages for Medical Device Depot my supervisor constantly stresses the importance of clarity. I always have to anticipate where the customer might experience trouble when ordering a product, and provide necessary clarification through embedded help. If I don’t include this explanation then the best case scenario is that the customer calls and asks, an unlikely possibility. At worst, the customer won’t buy the product, or accidentally order an incorrect product. Suffice to say, none of these scenarios are particularly desirable.
Here’s one example: when purchasing an emergency drug kit the customer must input additional information. I use popup help buttons to help clarify necessary details just in case the customer is uncertain. This not only saves time and trouble, it may prevent the loss of a sale due to lack of understanding.