How I write my Pluralsight courses

...
  • By Ivan Gavryliuk
  • In Pluralsight
  • Posted Friday, January 11, 2019

So far I've released three Pluralsight courses and this experience was just awesome. Writing courses is definitely not easy, in fact it's really difficult.

It's definitely not enough to know a subject very well, because when it comes to writing the course you'll realise you do have a few things that you were always lazy to check out, and they need to sound really solid in the course you are writing. For instance, what was that tricky parameters in the command line? What exactly a number means etc.

In addition to getting technical stuff ready, such as demos, screen recordings, general course plan, there is a lot of work related to getting the course published. I would say, the technical work takes the least of time in general, what takes most of the time is recording and editing your clips.

The actual process of recording is highly personal and every author finds his best approach over time. Mine changed dramatically from course to course, as I was trying to find the best one, and here is what I ended up at the end:

Prepare your scripts

In the beginning, I never paid much attention to scripts. Sometimes I would record screen and audio at the same time (especially for demo clips) and cut out the rest in Camtasia. This wasn't good as I was spending most of the time re-recording and editing a lot. In the last course I've ended up writing a text script of what I am going to say before I would do any other work, even before I prepare the slides. I'm using Microsoft OneNote for this, and I think it's the most underrated Microsoft product that is just excellent. OneNote syncs between devices, supports Ink (if you're into this thing, I use Surface Book for my work) and allows you to continue on the go when you only have access to your phone. Some phones like Galaxy Note 8 have pressure sensitive pen support, which makes you ink notes to sync naturally between devices too. I often use my phone to adjust notes and add quick ideas on the go.

In general, it's a good idea to script the whole course first, even if it's a rough draft, because it will give you a better idea what you are talking about. Doing it module by module causes potential issues like coming back to previous modules and trying to re-record some parts because you've missed them.

Before I start working on a certain module, I will make my notes perfect, so they are ready for recording.

Prepare slides

The next things I will do is create slides for the modules I'm recording. My notes are ready so I pretty much have an idea what slides should look like in my head. Slides are required for the editor to approve before I start producing the module. Once the slides are approved, I would record them to video separately without sound. I used to record audio and slides at the same time, however it creates unnecessary distractions like trying to click to the next slide and speak, this also records click sounds which I need to edit out whcih is a lot of extra work. Another bonus for recording slides separately is I don't need access to my recording studio - this literally can be done anywhere.

Record demos

When I record demos, I would have them ready beforehand. If it's a piece of code, I would create the sample application beforehand. In the beginning I would record me actually typing it from scratch, however this both bores the user and makes a lot of unnecessary editing - imagine how many typos and imperfections are going on during this process! Therefore I'd make sure the solution or script is working, and walk the user over how it works.

When preparing the demo material, I would put step by step instructions in my notes, so I know what I am talking about and remember how it was created.

Again, at this stage I will only record screen, pausing recording when necessary to make appropriate adjustments. By doing this I will get the shortest demo clips possible so it helps me to spend much less time editing.

Another thing about demos - while I'm waiting for my editor to approve the slides, I can parallelize my work by working on demos, because they are not in slides. Saves time.

Record and edit audio

I used to record audio at the same time as video and this didn't work well. The thing is, trying to get both right at the same time is hard, maybe I'm just sort of a person who likes to do one thing at a time. I used to record audio in Camtasia and edit it there as well. Unfortunately it turns out that Camtasia is far from perfect for these things. It does perfect job stitching all the materials together though.

For audio, I found it perfect to record separately first in Audacity, and edit there as well. Its a bit of a learning curve as user interface is not very intuitive for beginners but once you get it you'll never come back.

Audacity makes audio editing way more productive and pleasant than Camtasia, and you can apply various filters like remove pauses, adjust volume, remove silence and so on which eliminates a lot of manual editing steps.

Stitch it all together

When everything else is done the final steps is stitching it all together, and that's where Camtasia shines. Combining audio, slides, demos, annotating video and making it all flow is the final and the longest and the most tedious step. It easily takes 60% of the total time, is extremely long and honestly very boring. I didn't find a way to make it shorter yet, maybe I'm future. Still recording all the parts separately makes the overall process much quicker.

Once the clip is done, I will submit it to the editor and wait for approval.

Quite often (almost always) I need to make adjustments to the videos to comply with Pluralsight standards and just make learning experience more pleasant for users. That's where my editor does an excellent job by suggesting edits to make however they don't take much time, usually around an hour per module.


Thanks for reading. If you would like to follow up with future posts please subscribe to our rss feed.