In, This Is Why It Matters if Your User Guide Is Just an Afterthought, Bill Kerschbaum posits a scenario in which a potential customer, impressed by your glossy website, downloads a trial version of your software, is initially impressed, but then tries to figure out how to do something, is disappointed by the poor user manual and decides not to buy the full version.
My immediate thought on this was, but that is not what happens today. People don’t turn first to the user manual. The first thing they do is Google or ask their social network how to do something. Unless your user manual is online (preferably in the form of Every Page is Page One topics), and unless it ranks reasonably well in the search results for questions about your software, it isn’t even going to get a chance to disappoint. Instead, whether the user decides to buy your software or not is likely to depend on whether some other user has documented how they did the particular task they are interested in.
In other words: its a Google-first, manual-later-maybe-never world.
But then I realized that that is not actually how it works at all. The difference from the old world order of buy the product than read the manual is not that we now Google for the solution before we read the manual. It is that we Google for the solution before we buy the product. It is that we only hear about the product because it is mentioned in a solution.
Once we already own the product, of course, we then Google for how to solve new problems using it, because we already have money invested in it. But the scenario that Bill is describing is the one in which the user has not yet made a commitment to the product. The scenario he is interested in is the one in which the documentation makes a difference in the customer’s purchasing decision.
That, of course, is a scenario we should all be interested in. Show that docs drive sales, and you can justify your tech comm budget.
But the scenario in which docs drives sales is not the one in which the glossy website generates the lead and the user manual closes the sale. At least, that is not the only scenario. It is not the scenario that has driven my last several software acquisitions (paid and free).
The scenario that has driven my last several software acquisitions is this: I have Googled for a solution to a problem and I have found documentation (usually from a third party) that describes how to solve that problem using a particular piece of software. I then downloaded that software, because I needed it to complete the procedure I was following to fix my problem.
Here’s the really interesting bit. I must have seen this 100 times before the significance of it hit me. In so many cases in third party documentation, there is a step in the middle of the procedure that says, download product X. That’s right — the instruction to acquire the software is part of the procedure itself.
Here’s an example from a WikiHow page on combining PDF files:
1. Open NitroPDF. If you do not own NitroPDF, you can download the free trial here. It’s free for 14 days; after that, you’ll be prompted to buy a license.
Here’s another, from a discussion related to solving BAD_POOL_HEADER crashes in Windows, from http://www.geekstogo.com/forum/topic/316114-bsod-bad-pool-header/:
Run hard drive diagnostics: http://www.tacktech….ay.cfm?ttid=287
Make sure, you select tool, which is appropriate for the brand of your hard drive.
Depending on the program, it’ll create bootable floppy, or bootable CD.
If downloaded file is of .iso type, use ImgBurn: http://www.imgburn.com/ to burn .iso file to a CD (select “Write image file to disc” option), and make the CD bootable.
Pretty cool, I think. The reader is invited to acquire the software to solve a problem right in the middle of the procedure that solves the problem.
Though we have been telling ourselves for decades that our task is to document the user’s task, not the product, we have always worked on the assumption that the user has already purchased, and is committed to accomplish their task using, our product. We assume they already have the product.
But in a procedure truly focused on the user’s task, the selection and use of particular tools is not a presumed starting point for the procedure, it is part of the procedure.
This is what sales and marketing folk call the “call to action”. Inviting people to buy your stuff. Marketing 101 says that there is no sale without the call to action. So if we want to argue that documentation drives sales, where is its call to action? If you write as if the action had already taken place, there is no place to put the call to action.
Of course, in the days when we shipped user manuals in boxes with the product, there was no point in putting the call to action in the user manual, because the user would not have access to the manual until after they had already taken the action.
But on the Web, people do not lay out cash for a product hoping, based on the copy on the outside of the box, that it might solve their problem. They Google for a solution to the problem and buy the product because it is part of the solution they have found. They solve first, buy afterwards.
When we move our documentation to the Web, one of the key things we must remember, therefore, is that a major part of its audience includes people who have not bought the software, and whose modus operandi is to solve first, buy afterwards.
This means that when they hit your content, they don’t own your product, and are not necessarily even aware of your product. They have landed on your content because it contains a solution to a problem they are having. They will respond well if the content begins not with your product, but with their problem. And if you provide a good solution, you set up a perfect opportunity for a call to action that sells your product.
Today, people solve first, buy afterwards. Give them a solution that they can find on the web and that addresses their task, not your product, and you will have created the perfect conditions for a sale to occur.
Make the call to action. Then go and show management how you are driving sales, and ask for that tech comm budget that has been turned down so many times in the past.