You write "move that up a bit" and point vaguely at the top of the screen. The person reading it (or the agent reading it) guesses wrong, edits the wrong element, and now you are on round two. The fix is boring and reliable: name the part with a word the receiver already uses. A cropped screenshot plus "the primary button in the modal footer is misaligned" leaves nothing to guess.
Below is a working vocabulary. For each term there is a one-line definition and a note on when reaching for it saves a round. Borrow these when you type or dictate a comment, and pair them with the fuller pattern in structured feedback for LLMs.
Words for the thing you click or type into
Button: an element you click to trigger an action. Say which one. "The Save button," not "the button." A screen usually has three or more.
Primary button: the main filled call to action, usually one per view. Use it when there are two buttons side by side and you mean the emphasized one. "The primary button is the wrong shade of blue" is unambiguous.
Secondary button: the lower-emphasis action next to the primary, often outlined or ghosted. Naming it prevents the receiver from styling the wrong one of a pair.
Link: inline clickable text, not a button. Worth distinguishing because "make the link a button" is a real request and "make the button a link" is a different one.
Input or field: a box you type into. Add the label: "the Email field." Field names are the cheapest way to point precisely, since they are already on screen.
Placeholder: the grey hint text inside an empty field. It vanishes when you type. Reviewers confuse this with the label constantly, and "the placeholder is wrong" versus "the label is wrong" send the fix to different lines of code.
Label: the text that names a field, usually above or beside it. Persistent, unlike a placeholder.
Toggle or checkbox: an on/off control. Say which, because they behave and look different.
Dropdown or select: a field that opens a list of choices. "The country dropdown" beats "that menu."
Words for regions of the screen
Half of the vague feedback out there is a location problem, not a control problem. These carve the screen into named zones.
Header: the strip across the top, often with a logo and navigation. Footer: the strip across the bottom. Both apply to a page and to a component, so specify: "the modal header," "the page footer."
Nav or navigation: the set of links that move you between sections. Sidebar: a vertical panel on the left or right. Say which side.
Modal or dialog: a box that opens on top of the page and blocks the rest until you close it. "In the delete-confirmation modal" points the receiver straight to one overlay.
Toast: a small temporary message that slides in and fades out, usually confirming an action. Distinct from a modal because you do not dismiss it.
Card: a bordered box grouping related content, often one of many in a grid. "The second card in the pricing row" is specific.
Empty state: what shows when there is no data yet. Easy to forget, hard to describe without the term.
Words for the property that is wrong
Naming the part gets you halfway. Naming what is off about it gets you the rest.
Padding: space inside an element, between its edge and its contents. Margin: space outside an element, between it and its neighbors. "Too much padding in the button" and "too much margin around the button" are different fixes.
Alignment: how edges line up. "The icon is not vertically centered with the text" tells the receiver both the axis and the reference.
Contrast: the difference in lightness between text and its background. Reach for it in an accessibility review, where "the grey text is too low contrast on white" is an actionable claim.
State: the condition of a control, like hover, focused, disabled, or active. "The button has no hover state" is a precise gap.
Copy: the words on screen. Use it when the visual is fine but the text is wrong.
How the vocabulary reaches the receiver intact
Words alone still leave room to point at the wrong element. That is why the term travels with a picture. In Cobalt Capture you capture the screen in a browser tab, crop the still to the region you mean, and drop a numbered pin on the exact spot. Then you type the sentence, or dictate the comment out loud if you are on Chrome or Edge. The pin removes ambiguity about which control; the vocabulary removes ambiguity about what is wrong with it.
When you publish, the review becomes a public link anyone can open, plus a PDF, a Word document, and clean markdown at /r/<slug>/markdown. A designer reads the link. A client reads the PDF. If the work goes to a coding agent, the markdown carries your exact wording, so "the primary button in the modal footer" arrives as text the agent parses instead of a guess it makes. No install, no extension, and no signup to try it.
The habit is simple. Before you write a comment, ask two questions: what is this part called, and what property of it is wrong? If you can answer both, the receiver rarely has to ask a follow-up. For the full pattern of turning these named parts into feedback that gets fixed, read the words to use when describing a screen, then start a review and name the first thing you spot.