September 6, 2007
I received this note from a friend of mine who works in the same industry as I do:
The stereotypical technical writer sits in a cube all day and writes manuals, online help, or some combination thereof.
I work for a company that produces a complicated product everyone uses that requires no user manual: electricity.
So why would they need me?
Because they need good technical communication for software implementations, for technical training, for employee communications, and for IT presentations to upper management.
As the STC continues its quest to “tell our powerful story” it’s worth looking at this role. I don’t think I’m unique, but this approach to the profession is not widely promoted. Can you discuss this topic and solicit feedback from your readers?
We might even consider presenting on it at the STC conference in Philadelphia.
Tech Comm Generalist
Dear Tech Comm Generalist,
Thanks for your note. Your description of your work sounds familiar.
I bet there are a lot of technical communicators out there who play a similar role in their organizations.
We face some different challenges than others in our profession.
I will devote a few blog posts to this and maybe we can come up with a proposal.
PS. If a book written via a blog is a “blook,” is a proposal written via a blog a “bloprosal?”
Next: “Where do TCGs draw the line?” or “I don’t do windows”
September 4, 2007
Where has Holly been keeping herself?
Producing a less-than-10-minute video tutorial demonstrating some simple steps in our new timekeeping system.
What a learning laboratory that turned out to be!
And what a payoff! (Nicely coincided with my mid-year performance evaluation, actually.)
- 1 copy of Camtasia or Captivate
- 1 or more employees who are competent with Camtasia or Captivate
(thank you, Eric!)
- 1 script that has been thoroughly vetted by the subject matter experts and reads like a live training exercise.
- 1 decent microphone
- 25 hours to review the script, record the audio, produce the “bullet points,” capture the mouse movements, and insert the pop-ups or screen highlights
- A GUI that will not change in the middle of your recording session
- Business processes that will not change in the middle of your recording session
- The hutzpah, moxie, confidence (what have you) that the end product is worth the investment of time
Some of you who have been doing this for years are saying, “whatever,” but this is a first for me.
I believe we spent around 25 hours for 8+ minutes of video/audio.
The benefit is that employees will not have to sit in a live training session.
An additional benefit is the realization that if we can sum up the steps in a less-than-10-minute video, it really can’t be all that daunting a task to learn.
The hidden benefit is that every other project manager who is worried about implementing their new system now has another method to deliver training. [yes!]
What’s the downside?
- If the GUI changes before we go live, we’re toast. Have to re-record everything.
- If the business policies we describe in the audio change, we’re toast. Have to re-record almost everything.
- What’s missing from the video we produced? We didn’t explain how employees can look up their time off balances. We didn’t explain how managers approve time. We are planning to produce two more videos on these topics, but in the meantime, the powers that be will say, “Where is the rest of the information?”
These video tutorials are the wave of the future. Learn how to do them. Even your most amateur efforts will be met with rave reviews. Then employ continuous improvement methodology. (translation: do better each time)