If a picture is worth a thousand words, then how many words is a screencast worth? Obviously, quite a few more. Creating a good screencast, though, involves a lot more than just firing up Camtasia Studio or Captivate or whatever you’re using and starting to record.

I’ve been watching quite a few screencasts lately, and experimenting with creating my own. Through the twin processes of intently watching and trial and error experimentation I’ve come up with a few ideas about what makes a good screencast. For the most part, the process for creating a good screencast mirrors the process for creating good written documentation.

Know your audience

That’s rule one of developing documentation. It’s rule one of creating screencasts, too. Focus on the tasks that will be difficult for users of various levels of experience to accomplish. What those tasks are will vary from application to application, and can only really be identified through user analysis or by going through user feedback.

One way in which screencasts are widely used is to demonstrate the features of software. Obviously, in this case you want to show what the software can do and not how to do it. Avoid procedures, and highlight the results of procedures and interesting and advanced features of a product, and features that differentiate it from the competition.

Clarity is king

Ever watch an online video that was blurry or jaggy, and with bad audio? That’s definitely not what you want for your screencasts.

The video problems come from using too much compression. While a small file size is nice, you have to balance that need with the need to ensure that viewers can actually see what’s going on in the video. To get the right balance, you’ll have to experiment.

As for audio problems, the cause can be a bad microphone or bad audio settings or a defective sound card. It could also be that the person doing the voice over just doesn’t have the voice to do the job, or that they’re nervous and speaking too quickly or too softly or in a monotone. As Aaron and I wrote in relation to podcasting, you need to train your voice:

• Speaking loudly, but not too loudly. Project your voice, not to the other end of the room
  but to the microphone. Don’t whisper, but don’t yell.
• Treat recording in the same way you would a conversation. Relax, speak naturally. You’ve probably heard about that old technique of pretending you’re talking to a friend or family member.
• Pace yourself.
• Work on your enunciation. It’s easy to sound flat or condescending. Again, to get around this always try to view recording in the same way you would a conversation with someone you know.

Keep it short and focused

Just as no one wants to read a long procedure, no one wants to sit through a long instructional video. Focus on the task. Include any introductory or explanatory material in the text on the page that contains the screencast or the link to it. How short is short? Under two minutes, depending on your needs.

If the procedure is long, or is in many parts, resist the temptation to include it all in a single screencast. Break it up into multiple videos, and add a segue in the voice over — for example, In the next part of this process, you’ll apply the expression you just created to a search.

Storyboarding and scripting

A couple of weeks ago, I was chatting about podcasting and screencasting with someone. He said that he preferred podcasts and screencasts that were more off-the-cuff. It added, he said, a little more realism to the production.

I disagree with that. Working without a plan encourages you to ramble. Even with editing, a ramble still seems like a ramble. A plan, on the other hand, provides structure and focus. The plan comes in the form of a well thought out storyboard and script.

If you have time, mock up the shots in a screencast in software or on paper. You don’t have to do that; you can create a text outline that lists the shots. Then, use the shots to write the script.

Scripting can be tough. In order to keep a screencast within the time limits you’ve set, you need to write tightly. Again, it’s a matter of homing in on what you need to present, and eliminating anything superfluous. While you should strive to give the script a natural flow, avoid using colloquialisms and acronyms wherever possible.

Be serious, but not too serious

I keep mentioning that in this space, and I’m sure you’re tired of hearing it. I’m not saying that you should mimic the great videos from Common Craft, but try not to be too portentous. Make sure that your voice (or the voice of the person providing narration) conveys enthusiasm for the material. Don’t be a cheerleader, but don’t speak in a monotone drone, either.

That can be difficult sometimes. I mean, it can be difficult to be enthusiastic about setting up a supply chain routing or configuring a POTS line in a Web-based UI. It really a matter of training and using your voice, and speaking in a natural way. That’s a lot tougher than it sounds.

Tools and formats

I’m deliberately avoiding this topic. The choice of screencasting tools is a personal thing, like a toothbrush or a tie. Having played with a few applications in this space, I know what I like and what I don’t.

The same goes for formats. You’ll probably want to go with the lowest common denominator — Flash or MPEG. The FOSS advocate in me would normally push for Ogg Theora but not everyone has software that can play back Theora files, and they might not want to download that software.

I’ve undoubtedly missed more than a couple of points. What are your thoughts? Feel free to leave a comment.

Related posts:

1. Finding the voice that you need
2. Documentation: words versus video
3. Videos and screencasts have their drawbacks, too