A reviewer writes "the label here is wrong" under a screenshot of a settings page that has nine labels. The developer opens it, scans the screen, and picks the wrong one. Now there are two rounds of back-and-forth over a comment that should have been settled in one.
The fix is not a longer comment. It is a pin. Cobalt Capture lets you drop numbered pins on a captured still, and each pin points at one spot. When you write "2. This label reads 'Active' but the account is suspended," the number ties the sentence to a pixel. No guessing which element you meant.
Here are the practices that make pinned feedback land the first time, and what breaks when you skip them.
Pin one control per comment, not one screen per comment
Capture the screen, then place a pin on the single element your comment is about: the specific button, the specific field, the specific line of copy. Write the comment as a reference to that number. One pin, one issue.
This works because the receiver never has to translate. "Pin 3 sits on the Save button" is unambiguous in a way that "the save area" is not. A designer or developer reads the number, looks at the marker, and knows exactly where to act.
The failure mode is the catch-all comment. Someone captures a full dashboard and writes five separate problems in one text block with no pins. The receiver reads issue four, cannot find what it refers to, and either asks or skips it. Split those into five pinned items instead, and every one is actionable on its own. This is the core habit behind good UX feedback that gets acted on, and it is the difference between a review that closes and one that spawns a meeting.
Number pins in reading order, not the order you noticed them
When a screenshot carries several pins, place them so the numbers run the way the eye moves: top to bottom, left to right. Pin 1 near the top, the last pin near the bottom.
The reason is small but real. The receiver works through your pins in numeric order. If the numbers jump around the screen at random, they lose their place, backtrack, and miss one. Ordering the pins to match the layout keeps the review scannable, and it lines up with how the same screen renders in the exported document.
The failure mode shows up when a reviewer adds pins as they think of them. Pin 1 is in the footer, pin 2 in the header, pin 3 in the middle. The comment list reads fine on its own, but on the image the receiver hunts for each marker one at a time. Small friction, repeated across twenty pins, is what makes people stop reading a review halfway.
Say what is wrong and what you expect, next to the pin
A pin says where. The comment has to say what and what instead. "Pin 4: the error message appears only after submit; it should show inline as the user types" gives the receiver the current behavior and the target behavior in one line.
You can type the comment or dictate it with the browser's built-in speech recognition in Chrome or Edge, which is faster when you are walking a long flow. Either way, the comment carries the judgment the pin cannot.
The failure mode is the naked pin. A marker sits on a dropdown with a comment that just reads "this." The receiver knows you flagged the dropdown and has no idea why. Is the wrong option selected? Is the width off? Does it not open? A pin with no diagnosis is a question, not feedback. If you find yourself pinning without anything to say, that is a sign the item belongs in a broader note. Cobalt Capture also supports free-floating comments with no screenshot, which is the right home for anything that is about the whole page rather than one spot. More patterns like this are covered in the writeup of mistakes that make screen feedback hard to act on.
Reach for a crop when a pin still leaves too much noise
Pins work best on a screen where the target is visible at a glance. When the element is buried in a busy layout, crop the captured still down to the region first, then pin inside it. Cropping is the only image edit Cobalt Capture offers, and that constraint keeps reviews consistent: no arrows, no boxes, no scrawled labels that mean different things to different people.
The reason to crop is focus. A pin on a full 1440-pixel-wide page competes with everything around it. A pin on a tight crop of the checkout form has nowhere else to look. The design review case leans on this a lot, because spacing and alignment issues are hard to see until you cut the frame down to the two elements in question.
The failure mode is over-cropping. Cut so tight that the receiver cannot tell which screen they are looking at, and the pin loses its context. Leave enough of the surrounding layout to orient them, and no more.
What the receiver actually gets
Every pinned comment ends up in the same review. On publish it becomes a public link anyone can open with no login, and the same content exports as a PDF or Word document for people who want a file. It is also available as clean markdown, which is the format an AI coding agent reads if the fix goes that route. The pins and their numbers survive into all of those formats, so the reference you wrote holds whether a person or an agent opens it.
The receiver can reply on any individual item, and you can mark each one resolved as it gets fixed. That turns a pinned review into a working list rather than a static screenshot dump.
Start a new review, capture the screen you are looking at, and pin the first thing that is wrong. Write what you expect next to the number, and send the link.