How to Make a Developer Tutorial Video Without Screen Recording
Screen recordings are right for showing a tool. For explaining a concept such as OAuth, a drawn, narrated tutorial is faster to make, easier to follow and does not go stale when the UI changes. How to script one, with a scene by scene OAuth example.
By openCanviz • October 22, 2026
8 min read
To make a developer tutorial video without screen recording, split the tutorial into the concept and the keystrokes. Explain the concept as a drawn, narrated video: one actor or component per box, one message per arrow, built up as the narration describes it. Put the keystrokes in a README or code sample that the video links to. A good concept tutorial is 450 to 900 words of narration, three to six minutes at 150 words a minute, with no more than five or six lines of code on screen at any time. This works best for protocols, architectures and algorithms, such as OAuth, DNS, consistent hashing or a database index, where what matters is the order of events, not where to click.
When screen recording is the wrong tool
Screen recording is the default for developer tutorials because it is the easiest thing to start. Press record, talk, upload. It is the right tool when the subject is the tool: an IDE feature, a CLI workflow, a debugging session, a dashboard.
It is the wrong tool when the subject is an idea. Watching someone type through an OAuth integration shows you what they typed. It does not show you why there are two round trips, who holds which secret, or what an attacker sees. Those are the parts people get wrong in production.
| Tutorial subject | Better as | Why |
| How to use a debugger, profiler or IDE feature | Screen recording | The viewer needs to see where things are |
| A CLI workflow, start to finish | Screen recording, or a terminal cast | Exact commands matter |
| How a protocol works (OAuth, TLS, DNS) | Drawn explainer | The order of messages is the content |
| How a system or architecture fits together | Drawn explainer | Boxes and arrows, not windows |
| An algorithm or data structure | Drawn explainer | You need to watch state change |
| Building a feature end to end | Both: concept first, then a short recording | Different jobs, different videos |
Drawn tutorials have two practical advantages beyond clarity. They do not go stale when a console UI is redesigned, which happens to every cloud provider roughly once a year. And they do not contain your terminal history, browser tabs, API keys or notification pop-ups.
What it looks like
Here is a real example, a whiteboard explainer just over two minutes long, of what happens when you type a URL into a browser. Each component draws as it is mentioned: the browser, the DNS lookup, the server, the response.
Notice that nothing is on screen before the narration asks for it. That is the main thing a drawn tutorial does better than a slide: the viewer's eye is always on the part being explained.
Worked example: an OAuth tutorial
OAuth is the classic tutorial that screen recordings handle badly. The full flow involves four parties, two redirects and a back channel, and most recorded walkthroughs show only the client code.
Here is the scene list for a five minute tutorial on the authorization code flow with PKCE, which is the flow the current OAuth security guidance recommends for browser and mobile apps.
| Scene | What is drawn | Narration (key line) |
| 1 | Four boxes: User, App, Authorization server, API | "OAuth has four parties. The user, your app, the authorization server that knows the user's password, and the API your app wants to call." |
| 2 | The App with no password in it, a crossed-out key | "The whole point is that your app never sees the user's password. It gets a token instead, with limited scope and a short life." |
| 3 | The App generating a random string, code_verifier, and hashing it into code_challenge | "Before anything else, the app makes a random secret called the code verifier and keeps it. It sends only a SHA-256 hash of it, the code challenge." |
| 4 | Browser redirecting to /authorize with client_id, redirect_uri, scope, code_challenge | "The app sends the user's browser to the authorization server's authorize endpoint, with its client ID, where to come back to, what it wants access to, and the code challenge." |
| 5 | User logging in and approving a consent screen | "The user logs in on the authorization server's own page and approves. Your app is not involved in this step at all." |
| 6 | Redirect back to the app with ?code=... | "The server sends the browser back to your redirect URI with a short-lived, single-use authorization code. The code alone is not a token." |
| 7 | App posting to /token with the code and the original code_verifier | "Now the app calls the token endpoint directly, sending the code and the original code verifier. The server hashes the verifier and checks it matches the challenge from step four." |
| 8 | Token endpoint returning access_token and refresh_token | "If it matches, the server returns an access token, and usually a refresh token. Someone who stole the code from the redirect cannot do this, because they never had the verifier." |
| 9 | App calling the API with Authorization: Bearer ... | "The app calls the API with the access token in the Authorization header. The API checks the token, not the user." |
| 10 | Clock on the access token running out, refresh token swapped for a new one | "When the access token expires, the app swaps the refresh token for a new one, without asking the user to log in again." |
Scene 8 is the one that makes the tutorial worth watching. It answers the question every developer has about PKCE, which is what it actually protects against, and it does it by showing an attacker who has the code but not the verifier.
The code that goes with this tutorial, the actual request to /token in your language of choice, lives in the README. On screen, scene 7 shows only the five parameter names. That is enough to recognise them later.
Writing the narration
Name each message the way the spec does. If the parameter is redirect_uri, show redirect_uri. Viewers will search the docs for exactly that string.
One message per scene. An arrow, what it carries, and why. If a scene has two arrows, it is two scenes.
Say who can see what. For security topics especially: what is in the browser, what is on the server, what goes over the back channel. Most bugs are a secret on the wrong side of that line.
Keep code to the lines that teach. Five or six lines on screen at most, in a large font, and only when the line itself is the point. Anything longer belongs in a gist or repo the viewer can copy from.
Check every fact against the spec, not your memory. AI drafts and humans both get protocol details subtly wrong, such as which endpoint takes which parameter, or which token is sent where. The scenes are only as correct as the script.
Make it
- 1
Separate concept from keystrokes
Write the concept as a script. Put the commands and full code samples in a README the video links to.
- 2
List the parties and the messages
Who talks to whom, in what order, carrying what. For a protocol this list is the scene list.
- 3
Write one paragraph per message
450 to 900 words for three to six minutes. Use exact names from the spec and say who can see each value.
- 4
Paste it in and keep your wording
In openCanviz, paste the script, set the length, choose Keep my wording and pick whiteboard style, so each box and arrow draws as it is described.
- 5
Check every arrow and label
Go scene by scene and compare with the spec or your sequence diagram. Fix wrong names or directions in the editor without regenerating the rest.
- 6
Add a short recording only if needed
If viewers also need to see a tool, make a separate one or two minute screen recording and link the two. Do not mix them in one video.
Where drawn tutorials fall short
They do not replace hands-on practice. A viewer who watches the OAuth explainer understands the flow. A viewer who then implements it against a test authorization server learns it. Link the exercise.
They also hide real-world mess. An actual OAuth integration has error codes, clock skew and provider quirks. Mention the two that bite most often in a closing scene, and leave the rest to the docs.
For a tutorial about your own API rather than a public protocol, how to make a video that explains how your API works covers the consumer side. If the drawing style is new to you, what is a whiteboard animation video explains why it suits technical subjects. For tracing a request through your own services, see how to make an engineering architecture explainer for your team.
Common questions
Will developers actually watch a drawn tutorial? They watch the short ones. The drawn format reads as a whiteboard session from a colleague, which is how most engineers learned the protocols they know. Keep it under six minutes and make the code available as text.
Should I narrate it myself? For a channel or a personal brand, yes, because developers follow people. You can replace the generated voice with your own recording. For internal team docs, a generated voice reading your script is fine.
How do I handle code on screen? Short, large, and only when the line is the point. Show a single HTTP request or a five line function. Put the full working example in a repository and say its name in the last scene.
Can I make the same tutorial in another language?
Yes. Narration can be generated in other languages, Hindi and Spanish among them. Duplicate the project and switch the narration language. Keep identifiers such as redirect_uri in English, because that is what the code uses.
Write the message list first
Before any narration, write the protocol as numbered messages: from, to, what it carries. Ten messages is a five minute tutorial. Paste the script in and the whiteboard draws each arrow as it is spoken. It is free to start.
Turn any concept into an animated explainer
Type an outline, get a narrated, animated whiteboard video in minutes. No design skills, no timeline scrubbing. Free to start.
Keep reading
A public research video is not a shorter paper. It leads with why anyone should care, states one finding in everyday words, says plainly what it does not mean, and runs two to three minutes. A method, a jargon table, a worked script on sound and plant growth, and the checks to make before posting.
A home-made nursery rhyme video for a toddler should be slow, short and spoken, with one calm picture per line and the rhyme said twice so a child can join in. How to choose a traditional rhyme, script it, draw it, and use it in a way that fits the screen time advice for under-fives.
A good science video for young children answers one question they actually asked, in two or three minutes, with a simplification that is never false, and ends by sending them off to try something. A worked example on why the sky is blue, with the script, scenes and a kitchen experiment.
A child's birthday video works best as a one to two minute story with the child at the centre: their name, their age, the animals or things they love. A practical plan with a worked animal birthday party script, a scene list, and the privacy checks to make before you share it.