"Make it pop" is the most-quoted bad feedback example for a reason: everyone's received it, and nobody's ever been able to act on it directly. Vague website feedback isn't vague because the person giving it doesn't care, it's vague because writing specific feedback takes more effort than writing a feeling, and most feedback tools don't ask for anything more specific than a comment box. Here's what the difference actually looks like, side by side, and why it matters more once an AI coding agent is the one reading the note.
Vague vs. specific, side by side
| Vague (gets ignored or misread) | Specific (gets fixed on the first try) |
|---|---|
| "The hero section feels off." | "The hero headline is 48px on desktop but stays 48px on mobile too, it's overflowing the container below 400px width." |
| "Can we make the button pop more?" | "The 'Get Started' button in the nav has the same background color as the header, it doesn't read as clickable. Try the same blue as the hero CTA." |
| "The pricing table looks broken on my phone." | "The pricing table's third column gets cut off at 375px width, on an iPhone SE, the 'Pro' plan card is unreadable, only the left third is visible." |
| "Something's wrong with the form." | "The signup form submits successfully (network tab shows a 200), but the success message never appears, it's likely a state update that's not firing." |
| "This page feels slow." | "The hero image on /pricing is 4.2MB uncompressed, that's almost certainly the layout shift you're seeing, and INP on the CTA is over 200ms as it loads in." |
The pattern across every row: the specific version names a location, a measurement or condition, and often a hypothesis about the cause. The vague version names a feeling. Both are legitimate observations, the person who wrote "the hero section feels off" often did notice something real, they just didn't (or couldn't easily) translate it into something actionable.
Why the vague version costs more than it looks like
A vague comment doesn't disappear, it just moves the translation work to whoever has to act on it. "The button doesn't pop" turns into a developer opening the page, guessing which button, checking three CSS properties that might be the issue, and eventually replying "which button do you mean?" That round-trip, sometimes several rounds, is where most of the actual time in a feedback cycle goes, not in making the fix itself, which is often a two-line CSS change once the exact issue is identified.
This is the same translation-cost problem covered from the collection side in how to collect feedback on a website: the method you use to gather feedback either forces specificity up front or defers it to a slower back-and-forth later. A comment box invites "make it pop." A pin on a specific element, at a specific width, structurally can't be that vague, because the location and context are already attached before anyone types a word.
What makes feedback specific, concretely
Looking across the examples above, four things separate the useful column from the vague one:
- A named location. Which element, not which section. "The button" is ambiguous if there are three on the page; "the 'Get Started' button in the nav" isn't.
- A condition, where relevant. "On mobile," "at 375px," "after submitting" narrows a bug that might only reproduce under specific circumstances, most website bugs are conditional, not universal.
- What was expected vs. what happened. Not just "this is wrong," but "I expected X, I got Y." That distinction alone resolves a huge share of "is this actually a bug or working as designed" confusion.
- Evidence, when available. A screenshot, a console error, a network response code. You don't need all four fields to make feedback useful, but each one you include removes a question the person fixing it would otherwise have to ask.
We break this down as a fill-in-the-blanks template, expected/actual/repro/console/severity, in the bug report template, which is the same underlying structure applied specifically to bugs rather than open-ended design notes.
When the "specific" version is actually a measurement
The most persuasive specific feedback often isn't a sharper opinion at all, it's a number that turns a subjective complaint into a settled fact. A few of these are worth knowing because they close a debate instead of starting one:
- Contrast. "This text is hard to read" becomes "this pairing is 3.1:1, below the 4.5:1 WCAG AA minimum for normal text." Not a matter of taste, a failing grade against a published standard.
- Target size. "The buttons are fiddly on mobile" becomes "these tap targets are 18px, under WCAG 2.2's 24×24 CSS-pixel minimum (SC 2.5.8)." Checkable, not arguable.
- Performance. "This feels laggy" becomes "INP is 340ms; Google's 'good' threshold is 200ms or less at the 75th percentile since it replaced First Input Delay in March 2024." A specific target to hit rather than a vibe to chase.
Each of these swaps a feeling for a measurement, which is the fastest way to move a comment from "we should discuss this" to "here's the number, here's the fix."
Why this matters even more with a coding agent
A person reading "make it pop" can at least ask a follow-up question in the same conversation. An AI coding agent working from a written note doesn't have that option in the same way, it either guesses at what you meant (and sometimes guesses wrong, changing an element you didn't intend) or it stalls waiting for clarification that slows the whole loop down. A selector, a viewport, and a described expected-vs-actual state give an agent something to act on directly, the same shape of input that made the "specific" column in the table above actually usable by a person. We go deeper on why a screenshot alone, even a good one, still leaves an agent guessing in stop screenshotting your site into Claude.
Turning vague feedback into specific feedback, after the fact
Sometimes you're not the one writing the feedback, you're the one receiving "the hero feels off" from someone else and need to translate it before you can act on it. A few questions turn most vague comments into usable ones fast:
- "Which specific element, can you point to it or describe its exact position?"
- "Desktop or mobile, and if mobile, what width or device?"
- "What would it look like if it were right?"
That third question in particular does more work than it seems like it should, "feels off" often resolves into a genuinely specific observation ("the spacing above and below the button is uneven") the moment someone's asked to describe the fixed version instead of just naming the problem.
More examples, by category
The table above covers the most common shapes, but the same vague-to-specific pattern shows up across every kind of website feedback:
| Category | Vague | Specific |
|---|---|---|
| Accessibility | "The text is hard to read." | "Body text on a white card is #999 gray, which fails WCAG AA at normal size, needs to be at least #767676 to pass." |
| Navigation | "I couldn't find the pricing page." | "Pricing isn't in the top nav, it's only linked from the footer, and the CTA button in the hero goes to /signup instead." |
| Copy | "This section is confusing." | "The second paragraph under 'How it works' uses 'proof' to mean two different things in consecutive sentences, reads as contradictory on first pass." |
| Mobile layout | "The footer looks weird on my phone." | "The three footer columns stack correctly, but the newsletter signup input overflows its container at 320px, extends past the right edge of the screen." |
The accessibility row is a good example of how a specific tool claim (a WCAG ratio, a hex value) turns an entirely subjective complaint into something checkable and fixable in one step, no interpretation required.
A five-minute audit of your own feedback history
If you're not sure how vague your team's current feedback actually is, this takes five minutes: open your last twenty client comments or bug reports, whatever channel they arrive in, and count how many contain a specific element, a viewport or condition, and an expected-versus-actual statement. Most teams are surprised by how low that number is, not because anyone's being lazy, but because nothing in the collection process prompted for it. That number is a useful baseline to track if you switch to a more structured collection method later, it's the clearest before/after signal that the format change actually worked.
Where Shotline fits
The fastest way to skip the vague-to-specific translation step entirely is to make it structurally impossible to leave vague feedback in the first place. Shotline's pins are attached to the actual element on the live page, so a comment is automatically tied to a location, a viewport, and, when relevant, console context, the reviewer just adds the "what's wrong" part in their own words. Checking a color pairing against WCAG before flagging it as an accessibility issue is a good habit too, the contrast checker turns "this text is hard to read" into "this pairing fails AA at a 3.1:1 ratio," a specific claim instead of a feeling. If your review cycles are still running on comments like the vague column above, see the fuller comparison of website feedback tools or start a free trial, free for 14 days, no card required, then from $19/mo (billed annually; $25 month-to-month).
