We have been developing several small eLearning courses covering simple processes. Most last between 2 - 6 minutes each. I want staff to feel like they are sitting with a trainer and not a machine. Do you use a formal script when recording? Or do you have a SME walk through the training as you record.
I am not big on a formal script. I have participated in several courses that seem too formal with a script, almost as if a robot was reading everything.
What are your thoughts? How have your approached this? Thanks!
Depends on your purpose. If my purpose is to do a "down & dirty" tutorial on something (similar to many of the Screenr videos we see), then a script isn't necessary. But if my purpose is to provide something with a bit more polish, then I will create a script. The script is especially helpful to keep the time of your overall course/video down. When we talk off the cuff, we tend to ramble, and that adds to the time of the end product.
And you can use a script and not sound robotic. It's all is in the delivery. You can deliver the script in a way that's conversational by sounding . . . well, conversational. A lot of that's in the way you speak and the inflection of your voice.
So, here's my 2 cents. When I do narration, I always prepare a script. That prevents the hems, and haws, and umms...But, here's why it doesn't sound "scripted" (or so I've been told ).
Writing
The script is written in an informal style. It took me a while to "get this". A mentor a good while back said to me, "Becky, try this. Just tell me now, on the phone, about X, Y, Z." So, I did. He said, "Bingo, now write it that way."
Adding contractions, removing complex terminology, adding connecting words. These are some of the ways the writing differs from that of written documentation. I also include CAPS where I want special emphasis. Using personal pronouns (I, you, we) also conveys informality.
Narrating
First, I rehearse: out loud. I time the narration (I have a cool app on my Android phone that is a timer or a stopwatch).
Usually on the first read aloud, I go back and edit the script. I hear things that don't sound natural, or don't work. If I've been told I only have "x" minutes, and based on the timing, I may need to edit "down."
Then, I rehearse again. Sometimes again after that. This makes me comfortable and more familiar with the script, where I want to add emphasis, how to change my tone, that sort of thing.
Recording
When I record, I have the script in front of me. Depending on length, I may not even refer to it. But typically I do at least glance at it. My tone is conversational. I try to imagine I'm in a face-to-face, or looking over your shoulder. This can be the hardest part, since there needs to be a balance between informality and authority...that is, knowledge of the content, authority in that sense.
Love the suggestions above. My rule of thumb is almost always write a script. You can write as you would talk and you don't always need to follow the script exactly (when I finish a read I've marked up the script and may read something completely differently than it's written).
When I don't write a script, as in for a quick screenr or similar informal output, I will always outline the stuff I want to cover. This little job aid helps you to keep a good pace, cover all of your points, and avoid having to use brain cycles trying to remember whether or not you're forgetting something. It's a time saver in the long run. When you plan what you want to say, it usually comes out better.
With short "how to's", I use an outline to make sure we hit all the necessary points, but usually not a formal script if it's something that is just a quick production.
I've done it both ways. I've used Rebecca's method as well with good results. It really depends on the audience and the topic. I do mostly technical and systems training so a lot of what I do are 2-4min "performance support" pieces. If I'm doing something compliance related for HR or Legal, then it will be scripted for sure. If I'm showing our techs how to configure an application running on a terminal, I'm going informal with no full script. A lot of the performance support stuff is very quick turn around (sometimes hours) so that also plays a role as well.
Regardless of what you do, my belief is the less formal it is, the better.
Steve, you're right. I often "drift" a bit from the script when I actually record. And if the client requires text for the script (e.g., for ESOL, Deaf, or HOH), I play it and go back in to edit the changes for the written piece that I send to them along with the rest of the package.
And Rich and Steve, yeah, for in-house stuff, an outline suffices. And it's true, w/out an outline or script, I can't, as you put it Steve, "remember whether I'm forgetting something."
Great feedback and thank you! May be a dumb question, but if you were brought into a project to create eLearning on a area you are very unfamiliar. Do you try to learn the material to create the course? Or do you sit with the SME and record the steps and audio? Then sync and add your magic later. My company wants quick turn around so taking the time to learn every application and process seems impossible. Thanks.
You refer to the magical power possessed by an excellent ISD. If you've ever seen the show "The Pretender" - it's kinda like that
Not really. The secret to managing your time, in my opinion, is knowing just enough. This condition hinges on asking the right questions. Quickly getting to the tasks that are difficult to learn or perform, but still within the scope of your solution, is a great place to start. You don't want to take the SME's time to have him explain something that's not hard to take up on your own.
With software applications, I find that taking a quick hour or so punching the program in the face to see how it ticks primes me for interactions with the SME. Make sure you have basic familiarity before you sit down with the SME. Otherwise, you probably won't know enough to ask the right questions.
If you have recording software and audio capture, it's not a bad idea to capture the expert walking and talking through a task, even if you don't end up using it for anything but reference in the end. Just make sure you let the SME know that it may or may not be used so you don't set up a false expectation. They might not want to star. It's helpful to know that too.
I agree with Steve. I'll have the SME run me through the process a few times to make sure I've got it down, then I'll spend some time beating on it myself making sure I've got it down.
I've tried recording SME's directly in the past with mixed results. Because you understand the work flow around editing and working with the recording, there are little things you do that the SME will not (minimal cursor movements for example).
Side note: One of my pet peeves, I always clear my cache and turn off any autofil options when I'm recording demos. I hate seeing the stuff from the previous takes or dry runs in the final product.
I have used scripts and I've used outlines. I prefer scripts as it keeps me on the subject at hand. After a few attempts at recording and getting it right I've got the script pretty much memorized. Once I've got it in my head then I can make it sound more natural. It takes a couple of times to get it right, but presentation & tone of voice make it sound good.
Ditto Brian and Becky's comments. I ALWAYS require a script, no matter now short or long the project. The one time I let the SME talk me into not using a script because he was doing the voice recording, it took f-o-r-e-v-e-r to get the audio recorded. He kept forgetting something and having to redo. So my policy now is always have a script with every sentence exactly how it's going to be said. Becky's tips are excellent about making it sound informal, and I use those. Another reason we use a script is because we use a variety of our employees (we 're very low budget) with good voices as narrators, and rarely is that person the SME for that particular subject.
Depends on if it's a course or a tutorial. To me, it's a course when I've applied instructional design. There is a distinct flow, interactions, etc. I've done too much work on the back end to not have a script. I write it conversationally and make tweaks on the fly to keep it sounding as natural as possible
I consider it a tutorial if it's a shorter, on demand type of instruction/demo like a screenr. For these I just write down the main topics I want to be sure I hit and then wing it in between
Topic Knowledge
I can appreciate the challenge of having a lot to produce and not enough time to become an expert in every topic. However, it can be really tricky to create a course based on what someone else (likely NOT an instructional designer) has written. For this reason, I feel that I have to at least become proficient to deliver an effective and engaging course. Typically, I get the black and white steps from a SME. Then I jump into whatever it is and try to follow their instructions and explore on my own. I usually come up with a lot of questions from that. Whether it's holes in their instructions or a need to understand WHY I need to do it a certain way, it's typically those elements that I need to pass on the the learner because those are the very areas that would trip them up too. It's also all of the things that would be missed if I just took the material a SME gave me and converted it directly into a course
Having a script is critical to having a polished, error free recording. But, it is difficult to make a script sound conversational or natural when you write the first draft from scratch. I like to finish the eLearning piece and then record myself as I explain the content for each slide. I may end up with the hmms, ahhs, too much information, or missing information but it will sound natural. Then I can listen to the recording and create the script, removing and adding as necessary.
You can get a conversation feel with a prepared script. You just need someone who knows how to write such a script and a voice over person who knows how to sound conversational.
It seems to me that not having a script would actually take more time in the long run. And you surely need to be consistent. --Daniel
For me it all depends on the length and level of formality. For quick informal tutorials, one take and done, I won't take the time to write and edit a script (an outline will suffice). For longer tutorials I may outline and expand some portions to a script. For formal outputs, a script every time. That's my rule of thumb.
I think of this like I do my live presentations. Some portions I will script and practice extensively. Other portions I want to leave space for serendipity and improv. I never see opportunities for this in a formal package but I often do in the informal outputs.
We have been doing short 2-4 minute process type courses that are pretty cut and dry. Fortunately, the SME I have been working with is extremely good at what she does (she wrote the training manual). We have not been scripting so far. She has nailed it about 95% of the time and it feels more conversational. I still have to edit the audio, but there are minimal uhs and ums.
If the course was longer, I agree with going with a script. So far this has been working really well.
We are getting ready to create company wide harassment training. I will definitely have a script for that one.
This has been great feedback and I greatly appreciate it.
I feel very lucky so far. We had 3 SME's that train on this subject material. The other 2 were really good, but not as structured. Since I am fairly new to this as a full time gig, it was nice to ease my way in.
I usually get the SME to write the initial script, then I ask which bits are unnecessary
If you are recording someone else's words, as a "voiceover person", it's not neecessary to know the subject. As Steve says, "...You need to know enough...".
I usually find that by the time I come to recording a voiceover I have gained this in the design phase(s).
I would always recommend a script, but then the trick is to "bring the script to life" by using intonation, and use your voice as an instrument rather than as a tool to read words - I hope that makes sense.
When working with an SME, get them to tell you where the stresses are, where the intonation should be, etc. etc - it's incredible how just a few changes in they way you say something can change the way it sounds.
I no nothing about the mathematics of project management - however I managed to deliver a course yesterday which the client was totally pleased with.
There was a famous quote by Harry Houdini - "A magician is only an actor playing the part of a magician". I like serendipidy and improv just like Steve, however, I believe that those, (like jazz music...) come only when you have learned the piece, and then made efforts to feel it rather than just regurgitate the notes.
You can do identical takes from a script, meaning you can edit words from different takes together easily. If there is no script, editing multiple takes is much more of a project, as is cleaning up a single take with a lot of umms and ahhs.
Knowledge:
I like to work with stakeholders and define the goals of the training. Then I'll ask "As a student, what do I need to know to meet these goals?" And depending on their answer, I might ask again "And what background information do I need to know to understand that?" Then it's good to ask Bruce's question, "what here is unnecessary?" Essentially, this gives you your basic course outline in a 3 level knowledge hierarchy. Then, with a little pruning, that is where I'll spend my time learning what I need to translate the knowledge to my audience.
I'd say I'm infrequently a master of the subject matter beyond the core training, but I'm usually able to discuss the matter at hand. I'm the chimp that's learned to paint. Hand me the brush and I'll make you a picture, but ask me to explain art history and I'll just ask for a banana
I'd like to know what some of you think about showing the exact same words used in the audio narrative in the pane on the left in Articulate presenter. As a learner I want written narration or audio with the slides but not both so as a developer I tend to design that way. What's the best approach?
I am not suret that "best" exists, I have clients that like an exact copy (requiring it for Accessibiity reasons), I have clients that hate them being the same.
28 Replies
Depends on your purpose. If my purpose is to do a "down & dirty" tutorial on something (similar to many of the Screenr videos we see), then a script isn't necessary. But if my purpose is to provide something with a bit more polish, then I will create a script. The script is especially helpful to keep the time of your overall course/video down. When we talk off the cuff, we tend to ramble, and that adds to the time of the end product.
And you can use a script and not sound robotic. It's all is in the delivery. You can deliver the script in a way that's conversational by sounding . . . well, conversational. A lot of that's in the way you speak and the inflection of your voice.
Hi Brad,
So, here's my 2 cents. When I do narration, I always prepare a script. That prevents the hems, and haws, and umms...But, here's why it doesn't sound "scripted" (or so I've been told
).
Writing
The script is written in an informal style. It took me a while to "get this". A mentor a good while back said to me, "Becky, try this. Just tell me now, on the phone, about X, Y, Z." So, I did. He said, "Bingo, now write it that way."
Adding contractions, removing complex terminology, adding connecting words. These are some of the ways the writing differs from that of written documentation. I also include CAPS where I want special emphasis. Using personal pronouns (I, you, we) also conveys informality.
Narrating
First, I rehearse: out loud. I time the narration (I have a cool app on my Android phone that is a timer or a stopwatch).
Usually on the first read aloud, I go back and edit the script. I hear things that don't sound natural, or don't work. If I've been told I only have "x" minutes, and based on the timing, I may need to edit "down."
Then, I rehearse again. Sometimes again after that. This makes me comfortable and more familiar with the script, where I want to add emphasis, how to change my tone, that sort of thing.
Recording
When I record, I have the script in front of me. Depending on length, I may not even refer to it. But typically I do at least glance at it. My tone is conversational. I try to imagine I'm in a face-to-face, or looking over your shoulder. This can be the hardest part, since there needs to be a balance between informality and authority...that is, knowledge of the content, authority in that sense.
Hope that helps!
Love the suggestions above. My rule of thumb is almost always write a script. You can write as you would talk and you don't always need to follow the script exactly (when I finish a read I've marked up the script and may read something completely differently than it's written).
When I don't write a script, as in for a quick screenr or similar informal output, I will always outline the stuff I want to cover. This little job aid helps you to keep a good pace, cover all of your points, and avoid having to use brain cycles trying to remember whether or not you're forgetting something. It's a time saver in the long run. When you plan what you want to say, it usually comes out better.
With short "how to's", I use an outline to make sure we hit all the necessary points, but usually not a formal script if it's something that is just a quick production.
I've done it both ways. I've used Rebecca's method as well with good results. It really depends on the audience and the topic. I do mostly technical and systems training so a lot of what I do are 2-4min "performance support" pieces. If I'm doing something compliance related for HR or Legal, then it will be scripted for sure. If I'm showing our techs how to configure an application running on a terminal, I'm going informal with no full script. A lot of the performance support stuff is very quick turn around (sometimes hours) so that also plays a role as well.
Regardless of what you do, my belief is the less formal it is, the better.
Steve, you're right. I often "drift" a bit from the script when I actually record. And if the client requires text for the script (e.g., for ESOL, Deaf, or HOH), I play it and go back in to edit the changes for the written piece that I send to them along with the rest of the package.
And Rich and Steve, yeah, for in-house stuff, an outline suffices. And it's true, w/out an outline or script, I can't, as you put it Steve, "remember whether I'm forgetting something."
Great feedback and thank you! May be a dumb question, but if you were brought into a project to create eLearning on a area you are very unfamiliar. Do you try to learn the material to create the course? Or do you sit with the SME and record the steps and audio? Then sync and add your magic later. My company wants quick turn around so taking the time to learn every application and process seems impossible. Thanks.
You refer to the magical power possessed by an excellent ISD. If you've ever seen the show "The Pretender" - it's kinda like that
Not really. The secret to managing your time, in my opinion, is knowing just enough. This condition hinges on asking the right questions. Quickly getting to the tasks that are difficult to learn or perform, but still within the scope of your solution, is a great place to start. You don't want to take the SME's time to have him explain something that's not hard to take up on your own.
With software applications, I find that taking a quick hour or so punching the program in the face to see how it ticks primes me for interactions with the SME. Make sure you have basic familiarity before you sit down with the SME. Otherwise, you probably won't know enough to ask the right questions.
If you have recording software and audio capture, it's not a bad idea to capture the expert walking and talking through a task, even if you don't end up using it for anything but reference in the end. Just make sure you let the SME know that it may or may not be used so you don't set up a false expectation. They might not want to star. It's helpful to know that too.
I agree with Steve. I'll have the SME run me through the process a few times to make sure I've got it down, then I'll spend some time beating on it myself making sure I've got it down.
I've tried recording SME's directly in the past with mixed results. Because you understand the work flow around editing and working with the recording, there are little things you do that the SME will not (minimal cursor movements for example).
Side note: One of my pet peeves, I always clear my cache and turn off any autofil options when I'm recording demos. I hate seeing the stuff from the previous takes or dry runs in the final product.
I have used scripts and I've used outlines. I prefer scripts as it keeps me on the subject at hand. After a few attempts at recording and getting it right I've got the script pretty much memorized. Once I've got it in my head then I can make it sound more natural. It takes a couple of times to get it right, but presentation & tone of voice make it sound good.
Ditto Brian and Becky's comments. I ALWAYS require a script, no matter now short or long the project. The one time I let the SME talk me into not using a script because he was doing the voice recording, it took f-o-r-e-v-e-r to get the audio recorded. He kept forgetting something and having to redo. So my policy now is always have a script with every sentence exactly how it's going to be said. Becky's tips are excellent about making it sound informal, and I use those. Another reason we use a script is because we use a variety of our employees (we 're very low budget) with good voices as narrators, and rarely is that person the SME for that particular subject.
Scripts
Depends on if it's a course or a tutorial. To me, it's a course when I've applied instructional design. There is a distinct flow, interactions, etc. I've done too much work on the back end to not have a script. I write it conversationally and make tweaks on the fly to keep it sounding as natural as possible
I consider it a tutorial if it's a shorter, on demand type of instruction/demo like a screenr. For these I just write down the main topics I want to be sure I hit and then wing it in between
Topic Knowledge
I can appreciate the challenge of having a lot to produce and not enough time to become an expert in every topic. However, it can be really tricky to create a course based on what someone else (likely NOT an instructional designer) has written. For this reason, I feel that I have to at least become proficient to deliver an effective and engaging course. Typically, I get the black and white steps from a SME. Then I jump into whatever it is and try to follow their instructions and explore on my own. I usually come up with a lot of questions from that. Whether it's holes in their instructions or a need to understand WHY I need to do it a certain way, it's typically those elements that I need to pass on the the learner because those are the very areas that would trip them up too. It's also all of the things that would be missed if I just took the material a SME gave me and converted it directly into a course
Having a script is critical to having a polished, error free recording. But, it is difficult to make a script sound conversational or natural when you write the first draft from scratch. I like to finish the eLearning piece and then record myself as I explain the content for each slide. I may end up with the hmms, ahhs, too much information, or missing information but it will sound natural. Then I can listen to the recording and create the script, removing and adding as necessary.
You can get a conversation feel with a prepared script. You just need someone who knows how to write such a script and a voice over person who knows how to sound conversational.
It seems to me that not having a script would actually take more time in the long run. And you surely need to be consistent. --Daniel
For me it all depends on the length and level of formality. For quick informal tutorials, one take and done, I won't take the time to write and edit a script (an outline will suffice). For longer tutorials I may outline and expand some portions to a script. For formal outputs, a script every time. That's my rule of thumb.
I think of this like I do my live presentations. Some portions I will script and practice extensively. Other portions I want to leave space for serendipity and improv. I never see opportunities for this in a formal package but I often do in the informal outputs.
We have been doing short 2-4 minute process type courses that are pretty cut and dry. Fortunately, the SME I have been working with is extremely good at what she does (she wrote the training manual). We have not been scripting so far. She has nailed it about 95% of the time and it feels more conversational. I still have to edit the audio, but there are minimal uhs and ums.
If the course was longer, I agree with going with a script. So far this has been working really well.
We are getting ready to create company wide harassment training. I will definitely have a script for that one.
This has been great feedback and I greatly appreciate it.
Do you lend out your SME?
I feel very lucky so far. We had 3 SME's that train on this subject material. The other 2 were really good, but not as structured. Since I am fairly new to this as a full time gig, it was nice to ease my way in.
Brad,
I usually get the SME to write the initial script, then I ask which bits are unnecessary
If you are recording someone else's words, as a "voiceover person", it's not neecessary to know the subject. As Steve says, "...You need to know enough...".
I usually find that by the time I come to recording a voiceover I have gained this in the design phase(s).
I would always recommend a script, but then the trick is to "bring the script to life" by using intonation, and use your voice as an instrument rather than as a tool to read words - I hope that makes sense.
When working with an SME, get them to tell you where the stresses are, where the intonation should be, etc. etc - it's incredible how just a few changes in they way you say something can change the way it sounds.
I no nothing about the mathematics of project management - however I managed to deliver a course yesterday which the client was totally pleased with.
There was a famous quote by Harry Houdini - "A magician is only an actor playing the part of a magician". I like serendipidy and improv just like Steve, however, I believe that those, (like jazz music...) come only when you have learned the piece, and then made efforts to feel it rather than just regurgitate the notes.
Best of luck.
Bruce
Scripts:
You can do identical takes from a script, meaning you can edit words from different takes together easily. If there is no script, editing multiple takes is much more of a project, as is cleaning up a single take with a lot of umms and ahhs.
Knowledge:
I like to work with stakeholders and define the goals of the training. Then I'll ask "As a student, what do I need to know to meet these goals?" And depending on their answer, I might ask again "And what background information do I need to know to understand that?" Then it's good to ask Bruce's question, "what here is unnecessary?" Essentially, this gives you your basic course outline in a 3 level knowledge hierarchy. Then, with a little pruning, that is where I'll spend my time learning what I need to translate the knowledge to my audience.
I'd say I'm infrequently a master of the subject matter beyond the core training, but I'm usually able to discuss the matter at hand. I'm the chimp that's learned to paint. Hand me the brush and I'll make you a picture, but ask me to explain art history and I'll just ask for a banana
Love it
Bruce
I'd like to know what some of you think about showing the exact same words used in the audio narrative in the pane on the left in Articulate presenter. As a learner I want written narration or audio with the slides but not both so as a developer I tend to design that way. What's the best approach?
Hi,
I am not suret that "best" exists, I have clients that like an exact copy (requiring it for Accessibiity reasons), I have clients that hate them being the same.
I think it just depends on the situation.
Bruce
Does anyone know how to print from articulate?
I am taking the pain to add it in, but I want to get a printout with the script and the slide that it goes with.
Anita:
Go to "publish" and select the Microsoft Word. See if that gets you what you want.
It worked! I publised it as WORD and it worked.
Thanks,
Anita
This discussion is closed. You can start a new discussion or contact Articulate Support.