At work, I’ve been preparing to hold Web seminars (secretly, I cringe at the word “webinar,” which is reminiscent of a child mashing two colors of Play-Doh together). Through these meetings, I will be training users of an in-house office application. The globally scattered recipients of this training oversee between 50 and 200 people each. With members of the project team and the customer and support team, I have practiced the two sessions we will give.

Having trial runs has been useful to work out technical issues, but don’t kid yourself—the practices have made it apparent that though I have been documenting the system, I haven’t mastered every little detail about it.

The Great Writer Knows All

Being approached about providing live training began only recently. Those who typically have the big picture about an application as well as knowledge of the details are the business analysts, interaction designers, and some testers. Individual developers generally understand the piece of the application that they personally built, and some of the testers likewise grasp only those portions they have exercised. The manager understands the big picture but may not have all the details. And the analysts, designers, and testers’ time is at a premium.

Who else is there on the team who understands all the functionality?

Why, none other than—you guessed it—the technical writer. I’ve documented the whole thing, so I should know everything about it and be able to teach others how to use it.

The Help Author Needs Help? That’s It—We’re Doomed

Part of the problem is that I work on multiple projects. I’ve forgotten enough about these various applications that I find myself opening my own help. Not to mention the fact that I’m kept guessing by those adventurous developers’ changes to existing code.

Thus, as I proceeded to give this training, I found myself asking the quality assurance team lead a few times to verify statements I made. At these times, as soon as I explained a downstream effect or a limitation on user input, I suddenly was unsure whether I was giving the facts correctly. It didn’t happen frequently, but it did happen.

All this served to point out to me the importance of practicing the presentation ahead of time. Not only do these practices give the customer some reassurance and help you understand the necessary technical preparations, but they also reveal holes in your information. Once I have led these sessions a couple dozen times, I think I’ll be rather sure of myself, and I’ll have all the facts down. In the meantime, I have enjoyed becoming a technical writer–trainer hybrid.

And I hope I’m a little more graceful a hybrid than the word “webinar.”

No related posts.