You open the staging URL and something is immediately wrong. The header feels heavy. The button doesn’t sit right. You scroll back up and study it again and nothing resolves into a specific problem you can name. You know you have feedback. You just can’t find the words for it.
This is the design vocabulary gap. And it’s the engine behind most website revision back-and-forth.
Nielsen Norman Group’s research on design critiques puts it plainly: what trained designers describe as “inconsistent kerning and line height,” non-designers describe as “cluttered” or “needing more white space”. The perception is identical. The vocabulary is not. When feedback arrives in emotional terms rather than observational ones, it lands on the developer as a puzzle rather than a task.
You don’t need to learn design to give useful feedback. You need a description framework. Here are five techniques that work whether you’re writing a Slack message, leaving a comment in a website annotation tool, or recording a quick Loom.
Why does vague feedback cause so many revision rounds?
The mechanism is specific. “Feels off” gives the developer a sentiment but no subject — which element? Which property? Compared to what? Most developers will guess: they’ll pick the element most likely to be bothering a non-designer and change something about it. If the guess is wrong, you reply “it still feels off,” and the cycle starts again.
The industry standard for a website project is two to three revision rounds, with vague requests — unclear change descriptions that require clarification and rework — among the most common reasons projects exceed that count. The Carnegie Mellon Software Engineering Institute puts the broader pattern in focus: over 50% of rework in software projects stems from misunderstood or incomplete requirements. Website reviews aren’t software engineering, but the dynamic is identical. When the feedback is ambiguous, the developer resolves the ambiguity by guessing — and guesses compound.
Every extra revision round has a cost beyond the obvious. The developer touches the file again, context-switches out of whatever they were building, re-deploys, waits for your next pass. Getting the description right the first time compresses the cycle. The five techniques below all serve that goal.
How do you describe a visual problem when you only have a feeling that something is wrong?
Swap the evaluative phrase for an observational one. Evaluative phrases describe your emotional response to the page (“feels cluttered,” “looks off,” “doesn’t pop”). Observational phrases describe what is physically present, in specific terms.
The translation is usually simpler than it feels:
| What you reach for | What to write instead |
|---|---|
| ”Feels cluttered" | "The three columns are the same visual weight and there’s no clear place for my eye to land first" |
| "Looks off" | "The hero image takes up 40% of the screen but the text below it is tiny by comparison — they feel disconnected" |
| "Doesn’t pop" | "The CTA button is grey — it blends into the background instead of standing out from it" |
| "Needs more polish" | "The spacing between sections is inconsistent — some have large gaps, others have almost none” |
The pattern: replace the adjective describing your feeling with a sentence describing a specific element in a specific observable state. You don’t need the word “kerning” to say “the letters in the headline feel too close together compared to the body text.” That observation is precise enough to act on immediately.
Nielsen Norman Group identifies this as the core move for turning unactionable feedback into useful input — non-designers use different vocabulary to express design concerns, but what they observe is the same thing designers observe. As one analysis of vague design feedback found, language like “visual polish” or “this doesn’t feel right” signals dissatisfaction without clarity and “masquerades as feedback while lacking substance to drive meaningful improvements” — because different stakeholders interpret it to mean completely different things, from spacing to aesthetic modernism to brand coherence.
What if you can’t identify which specific element is causing the problem?
Name the layer instead. Most visual issues belong to one of four categories of a web page:
- Layout — the position, size, spacing, and proportion of elements relative to each other
- Content — what’s present versus what’s missing, misplaced, or placeholder
- Copy — the words themselves: headings, body text, button labels, navigation items
- Interaction — what happens on click, hover, scroll, or focus
When you can feel that something is wrong but can’t isolate the specific element, you can almost always identify the layer. “The layout of the hero section feels wrong — the CTA button is where I’d expect the main headline to be” is enough for a developer to scope the problem. They can look at the layout layer specifically, rather than scanning the entire page.
Nielsen Norman Group recommends structuring feedback around clear focus areas — user goals, visual design, brand alignment — specifically because unfocused feedback causes reviewers to give “any and all” notes and forces designers to reset the conversation to the original goals. Layer labeling does the same thing for website review: it narrows the search space and mirrors the categories developers already think in when making changes. A comment that lands in the same mental space the developer is already working in gets resolved faster.
Giving feedback in layers also makes batching easier. “Layout: the nav is too close to the hero. Copy: the CTA label should say ‘See the Product’ not ‘Learn More.’ Interaction: the mobile hamburger menu doesn’t close when I tap outside it.” Three distinct layers, three distinct tasks, no ambiguity about what kind of change each requires.
How do you provide context when the problem is really about the gap between what’s there and what you expected?
Use before/after framing. Most visual problems are relational — the issue is the difference between what exists now and what was there before, or between what exists now and what you expected to see. Before/after framing makes that gap explicit rather than leaving the developer to infer it.
The structure is: say what’s there now, say what the reference state is, say what the experienced gap is.
- “On the last version the navigation was dark and the page had clear structure — now the nav is light and I can’t tell where the header ends and the content starts.”
- “I expected social proof to come before the pricing section. Right now testimonials appear after the pricing table and it feels like they’re trying to walk back sticker shock.”
- “Before the last update the mobile layout stacked cleanly. Now the two columns try to sit side by side and the text is too small to read without zooming.”
Each gives the developer three things in one sentence: the current state, the reference state, and the gap between them. That’s a complete problem description — and none of it requires design vocabulary.
According to industry analysis of what causes website projects to exceed their standard revision rounds, fragmented feedback collected at different times and vague change requests are consistently in the top causes. Before/after framing is a direct counter to both: it consolidates the context into the comment itself and makes the request specific enough to act on without a follow-up thread.
What is the fastest way to eliminate “which element do you mean?” questions entirely?
Pin the comment to the element before you write anything. Spatial ambiguity — “the button on the right,” “that section near the bottom” — is the most common source of clarifying questions in website review, and it’s entirely preventable.
Visual feedback tools that let you click directly on an element and drop a numbered comment make the subject of feedback a fact rather than a description. The pin points. The number references. The developer reads pin 4, sees it’s on the contact form submit button, and reads your comment in that order. No spatial interpretation required.
Simpl_Markup handles this by design. When you click on any element on the live page in the Simpl_Markup web app, it drops a numbered pin and captures the exact URL, viewport size, and scroll position at that moment. The comment is anchored in space — so “the button at the top right” becomes impossible to misread. The developer sees pin 4 on the element on the Simpl_Markup canvas and receives a Slack notification with a cropped screenshot of exactly that element, alongside your comment. They don’t need to navigate to a staging URL and hunt for what you were looking at — the context is already there.
Pinning doesn’t replace good description. It removes the largest single source of ambiguity so your words only have to do half the work. A pinned comment saying “this button doesn’t stand out from the background” is immediately actionable. The same comment in a Slack message might take three replies just to establish which button.
For more on how visual feedback differs from the screenshot-in-Slack approach, Simpl_Markup vs. Screenshots in Slack covers that comparison in detail.
Should you tell the developer what change to make, or define what the outcome should be?
Define the outcome. Prescribing a specific change is the most common mistake founders make once they’ve gotten the observation right.
“Make it bigger” tells the developer what to do but not why. If the developer’s instinct about how to achieve prominence differs from yours, you’ve created another revision loop. “Make it stand out more” is still a prescription, just less specific. What you actually need to communicate is the goal — and developers, given a clear goal, make better technical decisions about how to achieve it than any founder-prescribed change usually produces.
UXPin’s research on stakeholder feedback loops found that teams organizing feedback around measurable outcomes — rather than implementation requests — reduced triage time significantly and achieved substantially higher approval rates than those using unstructured input. The principle translates directly: outcome descriptions make reviewers and developers speak the same language without requiring reviewers to understand the implementation.
The translation is usually straightforward:
| What you’re tempted to say | What to say instead |
|---|---|
| ”Make the CTA bigger" | "I want the CTA to be the first thing a visitor notices in this section" |
| "Add more whitespace" | "The sections feel like they’re pressing against each other — I want them to feel distinct when scanning down the page" |
| "Make the font bigger" | "I can’t read this comfortably on mobile without zooming in" |
| "Move this section up" | "I want social proof to appear before the pricing section, not after it” |
Outcome descriptions can’t be guessed wrong. The developer knows the design system, the technical constraints, and the visual language of the existing page — they’ll know how to achieve the stated goal better than any prescriptive change request usually lands. Your job is to define what success looks like.
The framework in practice
Put these five techniques together and a vague feedback session becomes a structured one. When you encounter something wrong on a staging page:
- Start with what you see. Replace the feeling with the observation — “the four items in this row are the same size and weight, nothing draws my eye first” instead of “feels cluttered.”
- Label the layer. Is this a layout problem, a content problem, a copy problem, or an interaction problem?
- Add the gap. What were you expecting to see, or what was there before that worked better?
- Pin the element. Click on it first. The spatial anchor removes the biggest single ambiguity before you’ve written a word.
- Define success. Tell the developer what the experience should feel like when it’s right — not the specific change you’re imagining.
None of this requires a design education. It requires the same observational discipline you’d apply to describing a physical problem to any specialist: what is it, where is it, what should it be instead.
If you’re doing reviews regularly, three website feedback patterns developers can’t act on covers the structural failure modes one level up from vocabulary — what happens when the framing itself is wrong, even when the individual words are right.
Simpl_Markup combines techniques 3, 4, and 5 into one flow. You click the element, drop the pin, describe the outcome, and Simpl_Markup posts the comment to your Slack channel with a cropped screenshot of exactly that element — viewport, scroll position, and element coordinates captured automatically. The developer reads it in Slack, understands it without a follow-up question, and fixes it once.
End the back-and-forth. Give feedback that lands.