One of the first tasks in creating video tutorials involves writing a script. In informal situations, you can simply use an outline or wing it, but corporate settings require higher professional standards.
I absolutely hate it when project managers get too involved in the video scripts. I've been on projects where the project manager decides to pull in several other team members and all write the script together alongside the technical writer. I can think of fewer situations that I detest more. (Maybe following behind horses in a parade and scooping manure in the hot sun -- maybe.)
One problem is that script-writing by committee invariably trends toward frankenstein-like copy. But there's an even larger issue. When you're writing a script, you often don't realize all the weaknesses of the script until you actually read it aloud in the simulation.
For example, let's say you painstakingly create a script and print it off. Then you go to your recording room and begin the simulation, narrating the script. When I do this, invariably I find myself making little alterations here and there to the script based on things I didn't catch as I wrote it.
If you're a voiceover artist reading copy for a commercial, you can't change the script. Even if it's poorly written, you pretty much have to stick with what's there.
But if you're a tech writer creating a video tutorial, you can change the script on the spot. I actually bring in two computers into my recording room -- one computer with the script, and one computer where I do the simulation. As I read the script, I can make adjustments to what I'm saying on the spot.
Here's my setup in my recording room. Since I have both a Mac and PC, I'm a little constrained. The Mac just records sound better (it's quieter and more stable). But my regular computer is a PC, hence the two.
For example, I may decide that I have too many explanatory sentences and need to get to the action more quickly, so I delete a sentence or two. I may realize that I don't need phrases like "click the Edit button in the upper-right corner"; I can just say "Click Edit" because the user can see exactly where and what I'm clicking, so location phrases may be unnecessary.
Sometimes I realize that a phrase that may have seemed smooth in writing doesn't -- for whatever reason -- read well. So I change it. Each time I read the script, I make some more refinements to it.
The ability to make adjustments to the script based on what you hear as you read provides incredible advantages in creating scripts. In Peter Elbow's Vernacular Eloquence, Elbow quotes two writers who explain how speaking writing causes you to make adjustments:
When writers are able to talk their text into a computer, speech errors may suddenly appear in writing. But other things may also happen. Writing, as some linguists and computer experts suggest, may change form and become more speechlike, more like a talking text than we now know, but yet not "speech writ down." There is also the possibility that what will emerge will be a "friendlier" text than could or would be produced by the pen or typewriter. (Horowitz and Samuels, intro)
In other words, when we speak the words, we trend towards friendly text. We don't always catch this when we work solely in writing mode. In writing mode, it's easy to slip into euphemisms, indirectness, or sophisticated structures. But when we hear ourselves saying these things, it just doesn't sound right. We need to make adjustments to make the text actually sound human.
Whatever you have, whether one computer on two monitors, or two computers and two monitors, or something else, the point is this: keep your script somewhat fluid in the recording room. You won't know exactly how it sounds until you read it. That little voice in your head that you heard when writing the words often plays tricks on you. It's a different voice from the one coming out of your mouth.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.