Journals by RSS
Journals by EmailThe rollout manager for one of the projects I’m with asked today for some way to provide trainers with a method of showing the application’s functionality in a controlled environment. It needs to be part of a presentation but not have room for surprises (those errors that appear at exactly the wrong moment, such as during demonstrations to the stakeholders).
Tag: training
Tags: Adobe Captivate, Captivate, technical communication, technical writing, training
#1
A stakeholder on one of the applications I work on provides support to users in certain roles. Individuals in these roles receive some paperwork upon assuming their positions, and this paperwork points them to the tutorials for this system. I was on the phone with him recently to discuss a change to the online help, and he said,
“When I point people to the tutorials, I rarely get a call back.”
This seems to prove my point that documentation can save on support costs. I don’t think it means that the users take the stakeholder’s response as meaning, “I don’t want to talk to you—go read the documentation instead” and just wash their hands of the whole thing.
#2
In another project meeting, we were discussing a training session for the users. The program manager asked the customer how long the session should be scheduled to take, and the answer was not more than two hours. The program manager said,
“The mind can absorb no more than the seat can endure.”
A good rule to remember when developing training. I found this saying attributed to Janet Trasli on the Web.
For a moment, let me just sing the praises of Akismet.
Me me me me me…
But seriously, if it weren’t for that nifty little plugin, my blog would be drowned under the disgusting tide of trash that hits it, and I’d have to shut it down. So if you post a comment and it never sees the light of day, I apologize; that may just be Akismet getting a bit gung ho.
Now on to the topic of the post here. Recently, the project I’ve worked on since I was hired at the LDS Church has been launched. With that, a chapter has closed of sorts. But perhaps there’s something of an epilogue.
I think the fact that I’ve spent the last three years documenting this software has contributed to my allowing myself to be pulled into support. I provided live training to a number of users, and I have offered my services to train others who may step forward and request it. It’s kept me busy lately.
I posted awhile ago about drawing a line between training and support. But I find that it’s tempting to remain involved at some level because of one key consequence.
I’m getting to know the users.
*Gasp!*
I have found myself wanting to start over with the documentation. My eyes have been at least partially opened. It’s backwards to try hand someone a manual and watch him or her start looking through it so that you can start writing that manual. But maybe the right idea is there. Maybe the thing to do is hand them a manual—any manual—and see what they do with it.
By the way, for “manual,” substitute quick-reference sheet or whatever other form of documentation you want. But what I’d like to do is get to know what my users do with documentation before the expense is made to create it. I’m getting off-topic here, and I intend to think (and post) more about this, but the idea is that spending time with the users has made me aware of how they approach documentation. In this particular case, I expect the need for tech support from me to drop off, but it has turned into a valuable insight for going forward.
As a technical communicator, whether you’re a writer or a trainer or both, have you found yourself troubleshooting with an end user? If so, you may have thought to yourself, “I’m a tech writer, not tech support!” The line between training and support is thin and therefore easy to cross. Some companies consider them the same thing, so there is no line as far as they’re concerned. But there are fundamental differences.
Or, Training by Web Conference: Episode 3
Refining our Web training sessions at work has been a challenging experience. We have had to work with some international callers whose local phone companies won’t let them dial any United States area code but 801, so calling our audio conference bridge was out of the question.
In addition, we are using WebEx conferencing software. Trying to juggle its functionality while demonstrating an application takes practiced skill.
Here are three suggestions for teaming up to make your training by Web conference more manageable.
