Decide What Must Be Said And Shown
Create two columns. Say on camera: why the problem matters; what decision shaped the workflow; which tradeoff or limitation matters; who the method is for; and what the viewer should do next.
Show on screen: the starting state; a product action; an artifact or source; the state change; the output; and the evidence behind a claim.
If an item appears in both columns, decide which mode carries the meaning. The other mode should support it, not compete.
Use The PIE Model
Person: the speaker establishes the question, point of view, and boundary. Their face is useful when trust depends on seeing who accepts responsibility for the claim.
Interface: the screen demonstrates the mechanism. The cursor, state, and narration should make one action understandable.
Evidence: the final view shows the artifact, result, comparison, or source. The speaker states what it proves and what it does not.
PIE gives the video a visual argument: person to interface to evidence.
Write A Three-Track Shot Plan
For every beat, write the spoken answer, visual state, and source.
A direct answer can use a talking head and an approved claim. A user problem can use the face or before-state and a brief or example. A workflow can use the screen and a safe demo. An output can use a screen with a label and the artifact. A boundary can use the face or a combined view and documentation.
This prevents the edit from switching views merely for motion.
Prepare The Screen
Use a dedicated demo account or safe workspace. Close messages, calendars, and private tabs; disable notifications; remove revealing bookmarks and filenames; use synthetic or approved data; enlarge interface text and cursor; place the camera overlay away from controls; preload slow screens; and test whether the product remains readable after cropping.
If a step takes time, say that the result is pre-prepared. Do not edit a wait into an apparently instant operation when speed is part of the claim.
Record From Question To Action
Map each prompt to a visual instruction. When asking what the user brings into the process, show the input and name what is safe to use.
When asking where human judgment remains, pause on review or approval and explain the decision.
When asking what a new user should inspect in the output, open the output, point to one feature, and state its limitation.
REC Content Studio can prepare questions from supplied context and record screen, camera, and microphone together. The speaker completes a guided solo interview; there is no live human interviewer. The recording is transcribed, and grounded highlight candidates can be suggested for rendering.
A Worked Example
Imagine a consultant demonstrating an audit template.
Person: "The template helps a team separate observable symptoms from assumed causes; a human still diagnoses the business."
Screen: open a safe example. Show the symptom field, evidence field, and alternative explanations.
Evidence: complete one row using a fictional scenario. Explain how the template prevents a recommendation from appearing before evidence.
Person: "A real diagnosis still requires access to the organization and qualified judgment. Use this as preparation, not a substitute."
The face carries the claim and limit. The screen carries the mechanism. The fictional row makes the example safe and inspectable.
Choose The Layout Deliberately
Options include full face, then full screen; screen with a small camera overlay; split screen for a true comparison; screen only with voice; or a face return for the conclusion.
Picture-in-picture helps when expression adds meaning. It distracts when it covers the interface or is too small to communicate anything.
Choose based on information, not aesthetics. Screen-only can still be accountable when the speaker is identified and the source is linked.
Edit For Visual Completeness
A transcript identifies spoken moments, but it cannot tell you whether the correct screen state is visible. Review audio and video together.
Keep the setup required to understand the task, the action that changes state, the visible output, and the limitation that affects interpretation.
Cut wandering and repeated navigation. Do not hide a failed step if the narration depends on the viewer believing it did not happen.
Write a highlight rationale with a visual requirement: "Keep the review screen in frame because it proves where human approval occurs."
Accessibility And Privacy
W3C recommends captions, transcripts, and descriptions of important visual information. Narrate meaningful changes: "The status moves from draft to reviewed after the owner approves it."
Avoid relying on cursor position, color, or tiny text alone. Provide written steps when viewers need to reproduce the workflow. Ensure captions do not cover controls.
Inspect the frame for notifications, customer names, account identifiers, browser history, and background material. Use safe data from the beginning; blur after recording is not a reliable confidentiality strategy.
Honest Limitations
Screen recordings age as interfaces change. Date version-specific demonstrations and link current documentation.
Combined recording requires more device resources and speaker attention than camera-only video. Test the setup and have a simpler fallback.
Some workflows cannot be shown publicly. Use an approved sandbox, diagram, or synthetic example.
REC Content Studio can capture and help cut the session, but it does not control the demonstrated product, verify screen contents, or publish the result.
Screen-And-Camera Checklist
Before recording, assign each idea to person, interface, or evidence; prepare safe data; close private material; map questions to actions; and test layout, audio, cursor, and crop.
After recording, verify screen and spoken claim match; inspect every frame; keep complete actions; add captions and visual narration; link current documentation; and label staged or synthetic examples.
Use the face when the viewer needs the person and the screen when the viewer needs the work. A deliberate visual plan makes the two reinforce each other.