How to turn a blog post into a video you can present yourself
Your article already holds a useful explanation. Choose one part, make it stand on its own, and record it in your own voice.
You have a blog post you still send people when they ask about your work. You'd like to explain the same idea on camera, but reading the article aloud gives you a long recording full of headings, links, and references to things outside the frame.
To turn a blog post into a video, choose one question from the article, rebuild its answer for someone who hasn't read it, and record that explanation with any example it needs. Check the spoken version against the source before you finish the edit. For a short video you present yourself, one useful section is a manageable place to start.
Here's a worked adaptation you can use to prepare your own recording.
Find the section that can stand on its own
Open an article you wrote or are authorized to adapt. Look for a passage that helps someone make a decision or complete a small task. An example, comparison, or explanation of a common mistake gives you something concrete to work with.
Write the question that passage answers. “How should I organize project files?” could require the whole article. “How can I tell which draft is waiting for review?” gives this video a clear boundary.
Before adapting it, check whether the advice still describes your current work. Update changed instructions, unavailable offers, and dated references. If the section depends on a source, check that source too; a sentence becoming spoken doesn't make its evidence stronger.
Choose a different passage if answering its question would require several missing explanations. A detailed reference table might work better as a resource you show and explain in a longer video.
Work from an excerpt, then rebuild the explanation
Imagine you wrote an article called “A simple filing routine for a shared project.” Its sections cover folder structure, draft names, review status, and archiving. You choose the review-status section.
The article, excerpt, workflow, and scripts below are original fictional teaching examples. They describe a proposed arrangement, not a tested system or customer result.
The written passage
Once you've named the file using the pattern above, record its review status in the project index. Use the three labels in the table below: Working, For review, and Approved to send. A new version number doesn't mean approval. The person responsible for sign-off must confirm that the draft is approved before you change its status. Use the worksheet at the end of this article to record the reviewer and the exact filename.
That passage makes sense inside its page. Read alone, it leaves questions: Which pattern? What index? Which labels? Where does approval come from?
Copying every surrounding section into the script would expand the video. Instead, decide which missing pieces this particular answer needs.
| Detail in the excerpt | Decision for this video | Reason |
|---|---|---|
| Filename pattern explained earlier | Leave the naming lesson in the article; use one sample filename here | The video teaches review status |
| “Project index” | Explain it as a shared list of files and their current status | A new viewer needs to know where the status lives |
| Three labels in a table | Say the labels and show a sample row | The explanation must carry the information the table supplied |
| A version number isn't approval | Keep the distinction | Otherwise a newer file could sound ready to send |
| Reviewer and exact filename | Include both in the example | Approval needs to refer to a particular draft |
| Worksheet at the end | Offer a simple row the viewer can make themselves | The video can deliver the lesson without requiring a download |
The spoken version
Which draft is ready to send? In this example, I keep a shared list with each file's name and review status. The labels are Working, For review, and Approved to send. Here's a row for “Spring poster v3.” It's marked For review, with Alex named as the reviewer. Version three tells us which draft we're looking at; it doesn't tell us Alex has approved it. Once Alex confirms that this exact file is approved, we can change the status to Approved to send. Try a row with three fields: filename, status, and reviewer. Use the approval process your team has actually agreed.
The new version names the task immediately and supplies the context the article previously carried. It also gives the viewer a small action they can complete without opening another page.
The final line matters: this is an illustrative filing routine. A team with several approval stages would need a process that reflects those stages.
Replace page references with something a viewer can follow
Search your selected passage for words such as “above,” “below,” “here,” “this,” and “as discussed.” Check each reference rather than deleting it automatically.
For the example, prepare a large sample row on paper:
EXAMPLE
Filename: Spring poster v3
Status: For review
Reviewer: Alex
Hold it beside you when you introduce the row. Let someone see the filename and status while you explain the difference. Keep it marked For review throughout that explanation; don't show Approved to send as though confirmation has already happened.
You can record this in one shot. If the row is too small to read beside your face, use a closer view or simplify its presentation. The B-roll guide can help when a separate supporting shot would make a detail clearer.
The University of Michigan's media-scripting guidance recommends conversational wording, planning meaningful visuals, and checking references that may become confusing when content changes. Apply that to the dependencies in your article: the video needs to supply the context it still relies on.
Compare the script with the source in both directions
First, read each spoken claim and find what supports it in the article or its underlying evidence. Check that rewriting hasn't broadened a recommendation, removed a condition, or turned an example into a reported result.
Then work backward through the selected passage. Ask what you omitted and whether the remaining explanation still works without it.
In our example, leaving out the filename pattern is reasonable because the sample already has a name. Leaving out confirmation from the reviewer would change the proposed process. Likewise, saying “the latest version is approved” would contradict the source.
Use this short adaptation note for your own post:
Source article and section:
Question this video answers:
Context I must explain aloud or show:
Claim or condition that must survive:
Detail I'm leaving in the article:
What the viewer can do after watching:
Keep the article and script together so you can compare them again when your advice changes. If you add a new example for the video, label it honestly and check it on its own merits.
Record the answer, then finish the clip
Say the script aloud with the sample in position. Allow time to point to the row and explain it. If the script feels crowded, reduce its scope or use the script-shortening exercise. Preserve the context that makes the answer usable.
Record the complete explanation. You can mention the full article afterward if it offers something extra, such as the naming routine. Make that destination specific and check that viewers can find it where you publish. The video should already have answered its own question.
For a portrait recording in your iPhone camera roll, Remixie can add captions and a chosen style, with preview and export. Review the sample row alongside the spoken explanation: the filename, status, and review condition should remain clear in the finished clip.
Play the exported video without the article open. Can a new viewer understand the task, follow the example, and take the suggested action? Then compare it once more with the source. Choose one useful passage today and complete that adaptation before planning videos for the rest of the post.