Is It Training or Documentation? Does It Matter?

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.

You highlight several important issues around documentation and training, and as someone who is responsible for providing information I recognise the problems you describe only too well. People with jobs like mine - often known as technical communicators, or technical writers, or technical authors - would love to provide information that supports user tasks, rather than information that just describes the product, but there are often obstacles that stop that from happening. For example:

1. Some companies see technical communication as a necessary evil, and teams are under-resourced in terms of staff, tools, and access to information

2. Some companies see technical communication as a cost centre, part of product development, and so it's kept separate from Training, which is seen as a revenue source. The result is often that there are two teams trying to provide parrallel information to customers, duplicating efforts and wasting resources.

3. The best sources for understanding user expectations and therefore producing documentation that supports users are from user research. This research is often undertaken and owned by a marketing department that doesn't see the need to share. Data about what features are least well understood - the features that need to be explained more fully in training or documentation - could be gathered by reviewing calls to Customer Service, but once again, it is rare for this information to be shared.

Training and documentation serve different purposes and both are needed, especially for new users or even for experienced users who are being introduced to a methodology or major tool feature that is new to them.

Those multi-day offsite training courses in a room full of workstations are expensive, but can be incredibly valuable. The knowledge & experience gained by using the tool in such a focused environment with an expert instructor cannot always be duplicated by simply reading the documentation and trying things on your own.

I first like to read specifications of every new tool or device I encounter. So this way, I know the most capabilites. Reading documentation is sometime time demanding and not many family member have patience. So manual I read as need basis.

First of all...a very nice article!! I am a user of EDA tools. I have not spent much time in reading the manual, but while reading through this article I realized that I might not be using the tool most efficiently. I think training is absolutely needed to start with. If the user works with an EDA tool frequently, training should be enough to start with. When ever I get stuck, I ask some expert users in my organization. That is quick...but if nobody is around to help, the manuals get handy then...only wish that the manuals are presented in a way which does not bore the user. :-)