The balance between training and documentation depends on context, scope, and value, for both the supplier and the user base.
Last week, we purchased a new flashlight for our son to use during a campout. Of course, immediately after opening the box, he started fiddling with it to see how it worked. The front of the package advertised that it had three modes -- high, low, and flashing.
Our son immediately learned that pressing the button once toggled the flashlight from off to on, and changed the intensity mode each time, resulting in off -- on HIGH -- off -- on LOW -- off.
But, how do you get to the flashing mode? OK, time to at least look at the box to see if it says what to do. Sure enough, it says to press the button quickly twice to get flashing mode. Cool. Off he goes!
Of course, while watching him go through this exercise, I picked up the instructions that he had dropped on the floor and took a quick peek at them. Like most instructions, the key points weren't immediately obvious, but I did quickly see that there were several very useful features he hadn't found by fiddling around.
In addition to the standard white light, you could get a red light for night vision. You could create a custom intensity mode in between the high and low settings, and then toggle between this mode and high. You could even lock the button so you couldn't accidentally turn it on in your pocket and waste battery life. Really? All this stuffed into a flashlight with one button? Yes, Toto, we now live in a world where a simple flashlight needs instructions.
In electronic design automation (EDA), this example is instructive in understanding our users' mindset. EDA vendors provide documentation for their products in the form of manuals.
While the product teams invest a great deal of time and effort to make their tools obvious and intuitive to use, there is just too much functionality stuffed in there to avoid the need for a manual. The manual is also the complete definition of the tool's functionality -- "this tool does this and this and this." So, manuals are clearly a part of the product, even if we don't expect many users to actually read them all the way through.
Of course, one reason that most users don't sit down and read the manual right away is that manuals are usually organized as functional descriptions of each and every feature and function of the tool.
What people typically want to know is "How do I use this thing to do a specific task" In the EDA world, there are easily thousands of such questions for each tool. Learning how to use a complex tool in context requires training. Typical training formats can range anywhere from an on-demand video to a multi-day off-site class, and usually involve an additional cost beyond the product itself.
At some point, the people who create the manuals realize that it can be difficult for new users to simply get started, or for experienced users to find information about a feature if they don't know what the feature is actually called, or how to put together different steps to accomplish a more complex task.
In response to these needs, they create new value by developing subsets of the manual content, such as quick-start guides, sample task flows, generic test cases, and the like... and shipping it with the documentation. This is all good.
At the same time, down the hallway, their friends in the training department realize that while a four-day class is sometimes entirely appropriate, and the only way to address all of the major functionality in a product, some of those classes can be broken down to focus on specific uses, or common process flows, and still provide the customer great value. They begin modularizing their class material into shorter and shorter sections, and maybe move the most common material into videos that can be accessed on demand and re-used across classes. Again, this is all good.