“This area feels confusing” flags a concern but leaves the designer guessing what to change. Mark the exact area on a screenshot and explain what you experienced there. A useful comment gives the observation, its effect, and the result you want to see.

Put the marker beside the evidence

Place a number in the margin and connect it to the relevant area with a thin line. Keep the button, text, or overflow visible. Give two distinct issues separate numbers. When the comment concerns the hierarchy of an entire area, outline the section instead of pointing at one control.

Establish context in one sentence

“Marker 1, at 360 pixels wide on a phone. The long heading wraps and pushes the checkout button down.” This tells the designer where it happened, under what conditions, and what changed. Add the build or sample data if it matters. Mark a personal preference as a preference.

Describe the outcome

“Move the button right” proposes a solution. “The primary action should be visible at a glance” gives a criterion for judging it. Keep those ideas separate so the designer can try a different solution. Put readability and access problems ahead of optional colour preferences.

Test the same conditions again

In the revised version, use the same width and text. Check the marked issue and look for new overflow elsewhere. Record the decision on the relevant task. If the old screenshot circulates later, the record shows which version fixed it and what changed.

Use one marker for one issue and one request

Imagine trying to point at the icon beside a heading, the button spacing and the text below with a single arrow. The designer may not know what to change first. For each marker, describe what you saw and the conditions in which it became a problem. For example, say that when the heading wraps to two lines on a phone, the close button overlaps the second line. That gives both a location and a trigger. Follow it with a testable request, such as keeping the button in its corner without covering the heading. Use a thin outline to show the affected region. A thick arrow over the text can hide the evidence. Include a full-screen image for context and a close-up for detail when useful. Matching numbers help the reader locate the same region in both. If the screenshot becomes crowded, separate the issues across images and give each file a distinct name.

Ask for a decision and an observation separately

When a note goes to a designer and a tester, give them different jobs. The designer can choose a fix, while the tester can check the behaviour at a specified screen width. Write down the device or window width and what happened before the capture. A problem on the initial page load is different from one that appears after an action. If the issue occurs on the second click, list the two steps leading to the annotated frame. When several people review a design, make sure they are looking at the same version. Instead of carrying every marker forward, close the resolved ones and check the open issue in its new location. Before sharing, remove personal details and unrelated chat lines from a separate copy of the screenshot. Then ask a colleague to follow the note without extra explanation. If they can reach the same point and recognise what needs to change, the feedback is ready to act on.