A feedback round trip costs a day. Someone reviews, someone reads, someone asks for clarification, someone re-reviews. Most of those round trips trace back to the same handful of mistakes on the sender's side. Here are the ones worth fixing first, with the concrete correction for each.
Writing "the spacing feels off" without a screenshot
Pure prose feedback is tempting because it is fast to type. You saw the problem, you described it, you moved on. The receiver then has to reproduce your path, guess which element you meant, and infer what "off" means in pixels or proportions.
Fix it by attaching the still frame. Capture the screen, crop to the area in question, and write the comment on that item. If the problem is one specific element inside a busy layout, drop a numbered pin on it. The reader now sees exactly what you saw and reads your sentence with the right element in mind. Our notes on running a UX feedback pass go deeper on pairing the still with the sentence.
Mixing bugs, opinions, and questions in one paragraph
A single long comment that says the button color is wrong, the form does not submit on Safari, and you are not sure whether step three should come before step two forces the receiver to triage your paragraph before they can act on any of it. The bug gets lost behind the opinion. The question never gets answered.
Split them. One item per concern, with a verb at the front of each comment: "Fix", "Consider", "Decide". A bug, a preference, and a design question are three different requests with three different owners and three different urgencies. Treating them as one item guarantees that two of the three slip.
Recording a five-minute video instead of capturing stills
Video feels thorough. You narrate as you go, you do not have to write anything, and you feel like you covered the page. The receiver now has to scrub through five minutes to find the thirty seconds that matter, take their own notes from your voice, and hope they did not miss anything at 2:14. There is also nothing to paste into a ticket.
For most review work, stills with comments beat video. Capture the frame at the moment something is wrong, talk through it using dictation, and the words land next to the image as text. The exception is reproducing a timing-dependent bug, and even then a still of the broken state plus written reproduction steps usually wins. There is a longer argument in screen capture vs screen recording.
Sending feedback in a format the receiver has to convert
You paste twenty screenshots into a Google Doc with comments in the margins. The developer opens it, copies each image to a ticket, rewrites the comments, and renumbers them. Or you ship a Figma file to a client who has never opened Figma and watch them get stuck on the login screen.
Send output the receiver can use directly. A developer wants a link they can open and a list of items they can work through. A client wants a public URL with no signup. A coding agent wants markdown. Cobalt Capture publishes one review and gives you all three: the link, the PDF or Word export, and the markdown view. For client work specifically, the pattern in getting feedback without making the client learn a tool covers the handoff in detail.
Skipping the priority on every item
Twenty items, none marked. The receiver picks the first one, which turns out to be the least important. Halfway through they discover item 14 was a launch blocker. You both lose half a day.
Mark each item P1, P2, or P3 in the first word of the comment. P1 means it blocks the release or the user. P2 means it is wrong but shippable. P3 is a nit you would fix if there were time. If you cannot decide between two levels, pick the higher one. The cost of getting a P3 fixed early is small. The cost of missing a P1 is large.
Forgetting the steps that got you there
A screenshot of an error message with the comment "this is broken" leaves the receiver guessing how to reproduce it. They try the obvious path, do not see the error, and reply asking for steps. Another day gone.
For anything that is not visible on first page load, write the path. "Log in as a new user, skip onboarding, open Settings, click Export." Three lines. The reviewer who saw the bug is the cheapest person to write those steps. Anyone else has to reconstruct them. This matters most for QA bug reports and for anything going to an AI coding agent, which cannot ask follow-up questions.
Reviewing the design file when the product is built
You leave comments on the Figma frame, but the engineer built from a slightly older version, or made reasonable judgement calls where the spec was ambiguous. Half your comments do not apply to the built product. The other half are real, but the engineer has to map each one back to the actual code.
Once something is in staging, review the built thing, not the design. Capture the real page, comment on what is actually there, and let the design file be reference rather than the artifact under review. The design review on the built product writeup shows the order of operations.
Not publishing because you want to clean it up first
You finish the review, then sit on it for two days planning to tidy the wording. The team waits. By the time you send it, the engineer has moved to other work and has to context-switch back.
Publish the rough version the same day. The receiver would rather have ten blunt items today than fifteen polished ones on Friday. Start a review, capture, comment, publish. Tidy in version two if it matters.