Here's a common scenario for creating a corporate screencast. In an effort to create a screencast, the project manager writes a script, carefully storyboarding it in PowerPoint. The project manager reviews the script with a committee several times to make sure it's perfect, and each member of the committee makes a few edits.
Finished with the script, the project manager hands the copy off to an audiovisual specialist, who creates the video by working with a professional voiceover actor. The voiceover actor reads the script in a studio, performing it with a professional-sounding voice, and the AV specialist tries to match the voice narration with video capture and mouse movements in the application. After a couple of weeks, they return the video to the project manager for review.
As the project manager reviews the script, he or she notices that the voice doesn't quite match the mouse movements. In fact, in watching the video, it becomes clear that the voiceover actor doesn't know the application at all. The person is merely reading copy (but reading it well, nonetheless).
The project manager also realizes, later, that edits need to be made to the script. The project manager forgot to include some notes, and other parts need to be removed. So the project manager makes changes to the script and sends it back to the AV specialist, who has to ask the voiceover actor re-record the script, and then the AV specialist needs to re-sync the audio with the mouse and screen. The whole process is so tedious it tries everyone's patience. After two months, they have produced one short video.
I mention this scenario because it's a commonly presumed setup for video tutorials in corporate settings. For a variety of reasons, I think it's better to have the technical writer create the video from start to finish, rather than involving audiovisual specialists and voiceover actors. Let me elaborate with three reasons why.
The technical writer knows the application better than anyone else on the project team (except maybe QA). Project managers and business analysts know how the app should generally work and the customer requirements, but they lack the nitty-gritty detailed understanding that comes from writing a book on the application. Developers and engineers only understand pieces of the functionality, not the full application. Support agents understand only problem areas. But when you write a book on an application, you get to know it well.
With a solid knowledge of the app, the technical writer can quickly and easily write video scripts for the most important features and functions. The technical writer is also a writer. Most likely the technical writer has conceptual chunks and general processes he or she can repurpose from the extensive help he or she already created for the app. If not, the writer can crank out words three times as fast as anyone else, and three times as polished and articulate on the first draft.
Writers also understand how to make text sound conversational. They include contractions, remove passive voice, and have a keen sense of clarity and organization.
Most importantly, if a tech writer knows he or she will be reading the script, you can believe that the tech writer will not write stiff, rambling copy. The tech writer will write with a clear idea of exactly how stupid or believable he or she will sound reading it -- and make adjustments accordingly.
If you hand off a script to a voiceover actor, he or she may read it well, but will it contain all the nuances, inflections, rhythms, and pauses necessary to explain the application's functionality in a believable way? Voiceover actors may have incredibly versatile, trained voices, but if they don't know what to emphasize, or where to slow down, or how the application they're explaining really works, their narration won't fit the content they're describing in a 100% believable way.
Moreover, most software video tutorials demonstrate steps for important tasks. The video instructs users to click certain options on a menu, to make selections, and press certain keys to perform a task in the application. The voiceover actor can pause between steps, but the pause lengths will be a guess at best. The AV specialist will need to edit the pauses to ensure they match up with the actual mouse and click movement on the screen. This is tough to do.
And if an AV specialist is producing the video to sync with the timing of the mouse movements, the AV specialist will also need to know the application. This learning curve presents more time drain on the production of the video.
The third advantage to having the tech writer produce the entire video is fixability. What happens when you realize, in retrospect, that your script left out an important note? What happens when developers decide to change a screen? What do you do when you realize you had the wrong button name in the script? What happens when you watch the video and just realize that it lacks interest?
If you have a third-party voiceover actor recording it, you have to send the script back to the voiceover actor to make the fixes. You hope that he or she can apply fixes to the script here and there, without having the recording sound like a hodgepodge of sounds. But submitting the updated script and waiting to receive it back may take a week at least.
Wouldn't it have been easier if you could record fixes on the spot and make all the adjustments on the fly? You'd be able to produce a new video within the hour. It may not be as professional, but users would already be watching it.
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 technical writing, authoring and publishing tools, API documentation, tech comm trends, visual communication, technical writing career advice, information architecture and findability, developer documentation, 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.