What to hand over before someone makes your product video

Write down the task the video demonstrates and the product state at its beginning and end. For a hypothetical file-sharing tool, that could be selecting a document, changing its access setting and opening it as an invited colleague.

List the captures needed to connect those states. A final image of the colleague's view doesn't show which access setting made it possible. If permissions are central to the explanation, include that step and record the conditions under which it works.

This example is hypothetical. Before handing over your own material, run through the real task and have a product owner check the sequence. Record where the source came from and when it was checked, so the recipient can distinguish current evidence from a reference saved months ago.

Keep current screenshots and recordings in a clearly named source folder. Put design explorations and reference videos somewhere else. Explain whether a design file is the shipped interface, an upcoming approved feature, or an illustration that should not be presented as real UI.

The distinction matters when an attractive mockup contains a control the product doesn't have. A designer might reasonably assume it was supplied for use unless the handoff says otherwise. An agent may make the same mistake while combining assets.

For reference videos, describe what you want to borrow: perhaps the way a result stays visible beside its input. The reference doesn't establish your product's behavior, and it shouldn't replace the captures needed to show your own workflow.

Use filenames that describe the state rather than a pile of numbered exports. In the sharing example, 'document-before-access-change' and 'invited-colleague-view' tell the recipient more than 'screen-final-2.' Keep the order in a small manifest rather than relying on the file browser to sort it correctly.

Note the controls and values that must remain visible. If the permission selector is essential, say so before someone crops it out to improve the composition. If the cursor position in a recording is accidental, identify that too.

Use deliberately prepared example data and inspect every capture before handoff. Look at browser tabs, notifications, account details and surrounding content, not only the center of the screen. This isn't a reason to invent product states; it's a reason to prepare a clean, accurate example.

Send the exact feature names and the wording the product team has approved. Mark claims that are conditional, such as access depending on an invitation, so they don't become universal promises in a simplified caption.

Include the current brand files with instructions for using them. A logo folder is easier to work with when it says which version belongs on each background and which older exports should be ignored.

Keep pronunciation notes with product terminology when narration is planned. The wording on screen and the way it should be spoken are connected, but they aren't necessarily the same text file. A phonetic hint shouldn't accidentally become the published feature label.

Name the exact logo variant for each situation instead of asking the producer to make it look right. For the fictional sharing tool, you could specify a dark wordmark on a pale opening screen and a light wordmark on the dark closing screen. Include a symbol-only version only if you've approved that use; cropping the wordmark isn't the same thing.

Keep the logo's proportions and the spacing already built into the supplied artwork. If you want a different arrangement, mark it as a design question rather than leaving the producer to stretch the file into an awkward slot. Check a still of both the opening and ending before animating the logo.

For type, record the family, weights and where the producer should obtain access. Permission to use a font in a finished video and permission to share the font files are separate questions. Adobe's own guidance distinguishes these uses for Adobe Fonts; check the actual provider's instructions for the font in your project instead of copying whatever files happen to be installed.

Have the person making the video confirm the requested weights are available before final layout. If a substitute is needed, approve it with a representative headline and product label so a last-minute change doesn't alter the line breaks throughout the film.

Adobe Fonts: video use and font-file sharing guidance

Your marketing background can use the campaign palette while the captured interface keeps its actual colors and labels. For the sharing example, changing a gray access label into a green success badge would alter what the product appears to be saying, even if the green looks better beside the logo.

Write down which changes are presentation choices and which need another product check. Moving a screenshot within the composition is different from moving a control inside that screenshot. Cropping unused navigation may be fine for the explanation, while cropping the permission setting could remove the condition that makes the result true.

Ask for a simple still showing the proposed brand treatment around the real interface. Review the two layers separately: does the surrounding design follow the brief, and does the product still show the verified state? That gives the producer a clear correction if one is right and the other isn't.

Here's a filled fictional handoff for the sharing workflow. The names, files, colors and assignments below are illustrative, not actual assets or approvals. Notice that it records one missing capture instead of pretending the package is complete.

Project: File-sharing feature announcement.
Example product: Paperbridge, a fictional tool.
Workflow: Invite a colleague, then show that colleague opening the document.

Brand owner: Maya, responsible for logo and typography decisions.
Product owner: Leo, responsible for access behavior and screen accuracy.

Opening: Pale background #F4F1E8 with paperbridge-wordmark-dark.svg.
Closing: Dark background #202A36 with paperbridge-wordmark-light.svg.
Logo instruction: Keep proportions; use the supplied wordmark rather than rebuilding it as text.
Type instruction: Use the approved family and weights in type-notes.txt. Producer confirms access before layout; Maya approves any substitute.

Product source: document-before-invite.png.
Purpose: Establish the document and current access setting.
Must preserve: The document title and restricted-access label.

Product source: invitation-step.mp4.
Status: Missing. Leo will capture the actual invite action before that scene is produced.

Product source: invited-colleague-view.png.
Purpose: Show the document opened by the invited colleague.
Must preserve: The same document and example account.

Presentation allowed: Reframe the capture and place explanatory text beside it.
Product change requiring review: Replacing the restricted-access label, altering the invite action or changing who can open the document.

Still to resolve: What should the video show if an uninvited person opens the link?

You can send this kind of note with a small asset folder rather than building a separate presentation. The useful part is that a producer can tell what to use, what must stay accurate, and whom to ask before filling a gap.

Before full production, ask for a rough account of which assets will appear and what changes between them. This can be a short scene outline rather than a finished storyboard. You're checking whether the handoff supplied enough information to reconstruct the intended task.

Resolve discrepancies against the product source. If the producer thinks copying a link automatically invites someone, the assets or notes haven't made the distinction clear enough. Fix the explanation before that assumption becomes part of the animation.

Keep the accepted manifest with the project and update it when an asset changes. Replacing a screenshot should have a visible reason, especially if the new state affects narration, captions or the result the viewer is promised.