How to give useful feedback on an AI product video

Before reviewing the animation, write one sentence about what someone should understand after watching. For this example, it's that a saved view brings back the same filters without setting them up again. That gives the review a concrete question: does the sequence actually show that happening?

The example is a writing exercise, not a customer case study. The question we're reviewing is whether a video makes the saved-view behavior understandable, without assuming that a confirmation message explains the whole workflow.

For your own product, keep the current interface or feature specification beside the video. If a reviewer asks whether a saved view is personal or shared with the whole team, answer that from the product before changing the script. A more confident line isn't an improvement if it promises the wrong thing.

Start by catching anything that would mislead a viewer: an invented control, a wrong label, a missing permission step, or a result that doesn't follow from the action. Those are different from preferring a different color or a quicker transition. Mixing them in one long list makes it difficult to know which changes are necessary before the video can ship.

If a task label is wrong, provide the approved replacement and identify every place it appears. For example, a note might say to replace Review checkout error with Review payment error in both the full list and filtered view. That's much more useful than asking for better copy and leaving the person making the revision to guess what the product should say.

A timestamp gets everyone to the same moment, but it doesn't explain what needs to change. Add the thing you see, why it matters and what a successful revision should preserve. That last part helps prevent a small fix from turning into a different video.

For example, if a save button gets clipped by the bottom of the frame, the useful note isn't just that the layout looks off. Name the button and explain that the viewer needs to see the complete action before the confirmation appears. You can leave the exact layout solution to the person or agent doing the work.

At the moment the filtered tasks appear, keep the full Save as Weekly review button inside the frame. The viewer needs to see what is being clicked before the saved confirmation appears. Preserve the two filter values and the two matching rows; don't shrink all the text to make room.

This sample note names the problem and the constraints without prescribing every layout decision. The person making the change can choose a clearer composition while preserving the product explanation.

A frame showing View saved tells you that a confirmation is present. It doesn't prove that reopening the saved view works. To review the explanation, follow the sequence through the return to All tasks and the later click on Weekly review.

Compare the saved state with the reopened state. If the status filter was Blocked and the sprint was Current, those same values should return, along with the matching tasks. A useful review note asks to show that continuity rather than simply leaving a success message on screen for longer.

Two published examples make this easier to spot. In ElevenLabs' ElevenAgents Architect announcement, the reviewed frames show a proposed procedure alongside Reject and Approve controls. The publisher also says changes require approval before going live. If a draft skips that distinction and says the agent has already fixed the problem, the feedback should restore the approval step rather than make the result sound more confident.

A sample note for that situation would be: 'Keep the proposal and approval controls visible together. Describe this as a suggested change awaiting review, and don't jump straight to a live result. Preserve the distinction between preparing the change and approving it.' This is an illustrative correction, not a claim that the publisher's video made that mistake.

Cognition's Dynamic Workflows announcement presents a different boundary. The report visible in the reviewed source frames describes an accessibility review of source files and explicitly excludes browser, screen-reader and runtime testing. That supports describing a source review; it doesn't establish that someone tested the running application or verified its accessibility.

A useful note here would be: 'Keep the report's review scope readable. Say the workflow collected source-review findings, rather than saying it tested the application. If this cut needs to claim runtime behavior, we need evidence of that separate check before changing the wording.' The correction names both the supported statement and what would be needed for a stronger one.

Our reference reviews covered sampled frames and the publishers' descriptions, not independent execution of either product. Use the same distinction in your own review notes: identify what the source supports, point to the wording or edit that goes beyond it, and state what the revised scene should preserve.

Reviewed example: ElevenAgents Architect

Reviewed example: Cognition Dynamic Workflows

If you can't read the saved-view name, first check its size, contrast, position and time on screen. A camera move might help, but it can also pull attention away from the click or make the label move while someone is trying to read it. The right feedback describes the reading problem before prescribing an effect.

A readable scene can come from changing the layout itself. Give the important control more space or remove competing detail before adding another caption explaining a label that's already on screen.

Try the video at its likely playback size. A full-screen desktop preview can hide problems that become obvious in a small feed. If important interface text won't be readable there, choose a closer view or a simpler scene rather than making the viewer decode a whole dashboard.

After a round of feedback, it is easy to focus only on what changed. But a revision can fix the label and accidentally change the filter values, remove the saved-view button or show a different set of tasks. Include the facts and relationships that should remain stable.

In the hypothetical example, the status stays Blocked, the sprint stays Current, and the same two task rows return. List those details in the brief so a revision doesn't improve the composition while accidentally changing the behavior being explained.

When several people review a cut, consolidate their notes before sending them on. Resolve contradictions such as making the product explanation shorter while adding three new setup steps. Otherwise the next version can satisfy individual comments while becoming harder to understand as a whole.

Put corrections that affect the product claim first, then clarity and readability, then preferences. Here is a reusable structure you can paste into a conversation without turning the review into a long production document.

Version reviewed: [link or filename]

What the viewer should understand: [one sentence]

Required correction: At [timestamp], [what is wrong]. Replace it with [approved fact or wording].

Clarity change: At [timestamp], [what is hard to follow]. The viewer needs to see [action or result].

Keep unchanged: [labels, states, assets or sequence that are already correct].

Check before export: Show the revised moment and the next step, then inspect the final file at the intended playback size.

If a note is a preference, label it that way. That gives whoever is making the revision room to explain a tradeoff instead of treating every comment as an equally urgent defect.

In Impractical's current workflow, the connected coding agent can edit draft source, rebuild a preview, inspect frames and request an MP4 export. That makes a specific revision possible, but it doesn't replace the review. Creating a draft isn't the same as approving a finished video.

Open the actual exported file and revisit the moments you changed. Check the surrounding transitions as well as the corrected frame, because a label can be right at one timestamp and still appear too late or leave too early. Confirm that you are reviewing the latest version rather than an earlier download.

The goal is to give the next person a clear decision: the product behavior is accurate, the action is understandable and the requested correction survived export. You can keep refining the visual style after that, but the useful explanation should already be there.