Streaming Learning Center

When working for a client, delineating and communicating the approval cycle is absolutely critical to workflow efficiency. I usually work through three stages.

First, I supply a script with a storyboard, which the client can change as much as necessary. Revisions at this point are cheap because nothing has yet been recorded. However, I advise the client that after script approval, major changes will result in additional fees. It’s critical to make this point clear, because otherwise many clients will simply delay review until the screencam is complete, at which point changes become very expensive and time-consuming.

Once I get script approval, I create a "draft" version of the project with narration. I put draft in quotes because it’s my sincere hope that the project is as close to final as possible, with the possible exception of adding the final voice-over talent to replace my scratch narration. On the other hand, it’s tough to comprehend how these projects will look solely from a script, so expect the client to make at least some minor tweaks. In one engagement that involved 10 separate video files, about 50% of my drafts were final; the others required further tweaking.

Typically, while creating the draft, I’ll notice a few necessary script changes, such as a window or mouse click that I forgot to include in the script. If these are minor, I make them without telling the client; if they’re major, I’ll send an updated script with track changes enabled in Word so the client can easily see and approve the changes.

Most of my client work has involved professional voice-over talent. In these instances, after receiving comments back from a client, I make the required changes to the video or narration and send an updated draft with my own narration back to the client for final approval. Once I have final approval, I send the final script and the final draft screencam to the narrator. After receiving back the final audio, I integrate that into the final draft to send to the client.

Hopefully, this is the third and final stage. It is critical that the client understands, up front, that any changes made to the final video, especially those involving voice-over talent, will involve additional charges.

Script Creation

The script creation process varies by project type. If I’m producing a simple tutorial for my own use—say, illustrating how to create H.264 files in Apple Compressor—I write the script while working through the steps for that operation.

I tend to provide very detailed audio with precise instruction of the required procedures. For example, I wouldn’t say, “Export the file to Compressor.” Instead, I’d say, “Click File, then Export to Compressor.” In my opinion, this level of detail assists the learning process by providing both visual and audio cues.

It’s not important that you adopt this style, as you may have your own thoughts in this regard. Rather, you should pick an approach—detailed or casual—and apply it consistently throughout the script. This is especially critical with work produced for third parties, since you don’t want the client to say, “You delineate all necessary steps here, but not here.”

When working up a screencam “advertorial” for a client, the process is more complicated. In most instances, the client has a printed brochure for the software program or web service that they’d simply like converted to a script. Sounds logical, but it never really works, for several reasons.

First, what reads well doesn’t always sound good, because most people don’t write the way they talk. Second, the point of a brochure is to tell the reader about the features and benefits of the product. The point of the screencam is to show the viewer the features and make sure they understand the benefits.

Third, this is the post-MTV age, and viewers won’t watch a static screen. Most brochures typically start with a paragraph or two about why the product is so wonderful, and it’s extraordinarily difficult to find appropriate screen activities to match these statements.

When I write the script, I prefer to start with a blank slate, not with prewritten text. In terms of approach, the unspoken agreement I make with my viewers is that if you spend a few minutes with me, I’ll show you why this product would really benefit you without insulting your intelligence with a lot of hyperbole. That said, I want the screencam to be a highly focused vehicle that effectively communicates the product’s unique selling propositions and convinces legitimate prospects that the product is right for them.

So I always start by asking the client, “What are the key value propositions that you want this tutorial to illustrate?” Once I have these, I try to identify product features that prove these themes and work them into the tutorial. The script itself has to be hyperbole-free; that’s my bargain with the viewer. Yet the key points must still be made in an organized and effective way.

My scripts typically start with a short statement that identifies the key value propositions that you want to prove in the tutorial. It might be “XYZ product works quickly, is easy to use, and produces high-quality output.” While the viewer hears this short recital, they’re watching the title fade in and out, and then I start the demo.

Then, throughout the rest of the script, I work to prove and then reinforce these themes. While showing a particular feature, I might say, “To run the perambulator feature, click here and choose this button. The program does the rest. Pretty simple, eh?” Or, “Here’s the output quality compared to product ABC; you can see that XYZ retains more detail and higher color resolution than the most relevant competition. Doesn’t it look better?”

Again, rather than telling the viewer what the benefit is, I show them and then reinforce the point with a “response check” to make sure they get it. In many ways, it’s the same technique I would use if demonstrating the product face to face.

Understand that scripting and screencam creation are very different roles, and you should charge for them separately. I like writing the script because third-party copywriters typically don’t understand the medium, and often write copy that’s impossible to implement, usually because there’s no screen activity to match the narration.

If the client wants to use a third party (or someone in-house) to write the narration, make sure they provide a storyboard with the narration. In other words, they have to define what will show on screen during each relevant segment of the narration, and static periods of even 3–5 seconds are not acceptable. Also, insist on precise definitions of screen activity, such as “Click File, then Save, and type the desired name in the Save window,” rather than “Save the file.” Otherwise, you’ll end up investing lots of time into the script without getting compensated for it.