The Ultimate Guide to Scriptwriting for System Training Videos

We've invested a lot of time and energy into refining our scriptwriting process for software and systems training videos. In this article, I'll share some considerations.

I've been working on our biggest project for Videobites over the past few months - 114 educational onboarding videos, delivered in three languages. We wrote detailed storyboards for each video and created each in Camtasia. You can see one of the final videos below.

I have done most of the scriptwriting myself and each day is giving me the opportunity to develop and refine our process. 

This article will not only share some tips and tricks, it will give you a checklist of decisions to make before you start script writing.

In addition to helping others, I also wanted to create a set of guidelines for instructional designers working on future Videobites projects, who can use this as a blueprint.

Why is this important?

Before we start, I should warn you that I am a bit anal when it comes to consistency across our videos! My hope is that through ensuring our videos look, feel and sound the same, we are communicating to future clients that we take pride in our craft and provide a repeatable, quality service.

Our process is also far more efficient if we reduce the opportunity for change during the review phase. Fixing videos with mistakes is fiddly, so getting it right first time is important.

I should also mention that this article is written for those using a voiceover artist, rather than anyone recording their own voice whilst capturing their screen - however, many of the tips actually apply to both situations.

The key is to make your script sound unscripted.

    1) Language

    The key to an engaging video is a voiceover that sounds like the person speaking is talking to you rather than reading to you. There's nothing worse than listening to a voiceover with someone reading from a script. The challenge here is writing a script which sounds conversational.

    We might have great English language skills, but we don't write in the same way that we speak. Here are a few techniques that we use to make our scripts sound less scripted.

    Contractions

    One of the easiest ways to do this is to use contractions. Let's take the following sentence as an example:

    "When you have finished entering all of the information, you are ready to print the form. There will be instructions on how to do this in the next window."

    Now if I was writing a support document, the above sentence would be fine. But we're writing for video. The best way that I can demonstrate this is for you to try reading that sentence out loud and see how it sounds. 

    It sounds scripted, right?

    So let's make some small changes to help this sentence flow better:

    "When you've finished entering all of the information, you're ready to print the form. There'll be instructions on how to do this in the next window."

    Adding contractions is a small adjustment but has a big impact. 

    Use don't utilise

    Whilst contractions go a long way to improve how the voiceover sounds, using simple language is also key.

    Let's look at another example: 

    "If the information displayed in the field labelled "Additional Info" is incorrect, you'll see an error message within the results." 

    We've used a contraction here - great. But we could drastically improve how this sentence sounds by simplifying the language:

    "If the information in the "Additional Info" box is wrong, you'll see an error message in the results." 

    The second example is much more conversational. Read the two sentences out loud and see which you think sounds best. 

    Bridging words

    When we talk, we often use bridging words to take us from one sentence to the next. Let's look at an example:

    "Philip is responsible for filling in all company level questions. On this dashboard, I’m already logged in. To get started, click on login at the top."

    By adding a few simple bridging words, we can make this sentence sound more realistic if it's being read out loud:

    "Philip is responsible for filling in all company level questions. Now, on this dashboard, I’m already logged in. So to get started, just click on login at the top."

    This example is probably a little over the top - but I wanted to show the technique in the shortest example possible. Adding a few bridging words will help your voiceover sound natural.

    Eats, shoots and leaves.

    2) Guidance

    Have you ever sent someone an email or text message, only to find out the recipient took offence because they 'read it differently' to how you had intended? Well, this happens all the time when writing scripts. 

    The simple solution is to provide extra guidance in addition to the actual script, so the voiceover artist knows how to read it.

    We use a couple of different techniques for this - one is to add a note to any ambiguous sentences. We actually have a box in our storyboards where we provide a detailed explanation if there is something we think might be interpreted incorrectly by the voiceover artist.

     A snapshot of a storyboard

    Pronunciation

    Another issue is errors with people, place or company names. A recent example of this was when our voiceover for the abbreviation 'SMETA' was pronounced incorrectly. 

    This abbreviation is commonplace within my clients business, so it was obvious to us how it should be pronounced (it should rhyme with 'feta' - as in the cheese!) but this wasn't obvious to the voiceover artist.

    When the client reviewed the audio files, they noticed it had been pronounced incorrectly. This meant we had to send that clip back to re-recorded, which incurred additional cost and also delayed production.

    So as you can see in the image above, we now add notes to all scripts with guidance on any ambiguous words.

    Emphasis

    Another way to make sure the voiceover artist reads the script in the way it was intended, is to highlight words that need emphasising. Let's look at another example. Read the next sentence out loud in a neutral tone:

    "I didn't say you stole my money”

    Pretty straightforward, right? But what if the sentence had a different meaning? Try reading it out loud, whilst emphasising the highlighted words:

    • "I didn't say you stole my money”
    • "I didn't say you stole my money”
    • "I didn't say you stole my money”
    • "I didn't say you stole my money”
    • "I didn't say you stole my money”
    • "I didn't say you stole my money

    As you can see - that's 7 variations for a single sentence!! 

    By highlighting words you want emphasising, you'll ensure that the final audio files will reflect exactly what you were expecting.

    Phrases

    Sometimes you will use phrases, that if you don't label, might not be recorded correctly. Let's look at an example, In a recent project I worked on, one of the phrases used within the software was 'good examples'.

    Now, if I had just written that into a sentence like this:

    "...the supplier won’t need to add corrective actions for this issue type. This is the same for good examples..." 

    ...the voiceover artist would have assumed that we were just talking about examples that were 'good', and not emphasised that phrase correctly.

    So for phrases that need additional emphasis, I use inverted comma's and/or capitals to ensure they stand out. So that same sentence would be typed like this:

     "...the supplier won’t need to add corrective actions for this issue type. This is the same for 'Good Examples'..."

    This makes it very clear that it is a stand-out phrase and is more likely to be captured correctly. 

    Pauses

    When we speak, we use pauses to give certain part of sentences extra emphasis.

    I use commas as a quick way to show pauses when I'm script writing. Whilst it may not be grammatically correct, it's a simple way to show the voiceover artist where you want them to pause when they're speaking..

    Let's look at an example:

    "I can fill in each of these questions and connect the answers to Philip’s individual sites. This means he'll save time by not having to fill in the same information several times and also guarantees that they're all consistent."

    If you read that out loud, you will naturally pause several times throughout the text. But that doesn't necessarily mean the pauses will fall at the moments the scriptwriter wanted them.

    Now, if we look at the following example, we would probably all agree that the text isn't grammatically correct. But the voiceover artist has a much better idea for how to read this out:

    "I can fill in each of these questions, and connect the answers to Philip’s individual sites. This means, he'll save time by not having to fill in the same information several times, and also guarantees that they're all consistent."

    Adding a few commas where you expect a pause will make the voiceover artists job easier.

    You? Me? We? Huh?

    3) Perspective

    We can use a variety of different options for who we refer to in our scripts.

    I could be talking about how I move my arrow and click on the button.

    You could be talking about how you need to move your arrow so you can click on the button.

    Or we could be doing this together and talking about how we need to move our arrow so we click on the button.

    One might get even more highbrow and move one's arrow to click on one's button!

    That last example is clearly a little over the top. But you can see where I'm going. If you don't specify in which person you plan to write your script, you'll be jumping back and forth and using a combination of each. 

    Even if you have decided which of these you plan to use, if this hasn't been discussed with your review team, and they start adding suggestions for changes using different language, you'll end up with inconsistencies across your script.

    Probably the easiest way to approach this is to use a combination of these concepts. In our scripts, we tend to talk about ourselves (me, I, we) when we're demonstrating something. But then if we talk about something that the user will do, we would switch to them (you).

    It's entirely possible to write a script without referring to anyone - but I really like videos to acknowledge that real people are involved. I think it makes the whole thing feel more personal.

    4) Terminology

    To guarantee consistency across all videos, we create rules for the terminology we plan to use.

    Let's look at an example. The following three sentences provide the same instruction but use different terminology:

    • "Move your mouse to the top of the screen, hover your arrow over the house icon and select the first item from the list." 
    • "Move your mouse to the top of the page, hover your mouse pointer over the house symbol and choose the first item in the menu.
    • "Move your mouse to the top of the window, hover your mouse over the little picture of a house and click the first item in the box." 

    Whilst they are all giving the exact same instruction, we'll create a more consistent video library if we use the same language. 

    Some of the more common variables we come across are as follows (showing our preference at the beginning):

    • Mouse pointer - cursor, mouse, pointer
    • Page - webpage, screen  
    • Select - choose, pick, click (this is important if your videos are teaching a system that may be used on both a computer or phone, where a mouse 'click' would actually be a finger tap' instead).
    • Menu - list, dropdown menu
    Remember viewers have the benefit of skipping back if they miss an instruction.

    5) Detail

    When you write scripts for software or systems, there is obviously a lot of instruction regarding specific functionality. Let's look at an example: 

    "When you've finished, move the arrow to the bottom and click 'Submit'."

    Seems like a straightforward instruction, right?

    But let's look at some alternatives, starting with the least descriptive: 

    • "When you've finished, click 'Submit'."
    • "When you've finished, move the arrow down and click 'Submit'."
    • "When you've finished, move the arrow down to the bottom of the page and click 'Submit'."
    • "When you've finished, move the arrow down to the bottom of the page and click on 'Submit'."
    • "When you've finished, move the arrow down to the bottom of the page and click on the 'Submit' button'."

    So which is right? 

    This depends on the objective for each video and the audience. Is the most important factor short videos? Or is effective learning more important thing?

    But there are other considerations too. For example, how familiar are the end users with the software we're teaching? 

    If these are onboarding videos and they're not familiar, it would make sense to be more descriptive whilst they become comfortable navigating around the interface.

    It’s a fine line between being helpful and patronising!

    And how familiar are our viewers with technology in general? If you're creating videos for people who aren't, you may need to be really descriptive. It's a fine line between being helpful and patronising! 

    But remember, if you're writing for video, our viewers will have the benefit of skipping back if they miss an instruction. So my general rule of is 'less is more'. It's easy to go overboard, but we should value our viewers time and get them to the end of the video as quickly as possible.  

    One technique you might want to consider if you're creating a series of onboarding videos, is to make the initial videos more descriptive and then reduce the level of detail as they become more familiar with the technology. 

    Conclusion

    As you can see, a lot goes into scriptwriting for software systems videos! And the really important takeaway from this article, is that planning as much of this as possible before you start writing, will go a long way to saving you time editing and fixing mistakes later on. (Even if that's a decision not to worry about some of these things).

    Have I missed any crucial points? Is there a better way to do this? Please let me know in the comments section below.

    Ant Pugh

    108A Tooting Bec Road, 108A Tooting Bec Road

    eLearning Learning