“Make it pop.” If you build websites for a living, you've received that note. Maybe this week. And somewhere between reading it and replying to it, you did the math: one vague sentence equals one guess, one revision, one more round of “closer, but not quite.”
Here's the thing though: the person who wrote “make it pop” wasn't being lazy. They saw a real problem. They just didn't have the words, or the format, to hand it over in a usable state. Good website feedback is a skill, and like most skills it's easiest to learn from examples.
So that's this post. First, the four-part anatomy that separates actionable feedback from noise. Then twelve website feedback examples, each shown as the vague version and the rewrite. Then a simple process for how to review a website so the good notes actually happen, round after round.
The anatomy of actionable feedback
Every useful piece of website feedback, whether it's about a color, a sentence, or a broken button, contains the same four ingredients. Miss one and somebody has to come back and ask. Miss two and they start guessing.
Where, exactly. The page, the section, the element, and the viewport. 'The hero headline on the homepage, mobile view' beats 'the top part' every time.
What you actually see and why it's a problem. 'The headline gets lost against the photo' is an observation. 'It's ugly' is a verdict, and verdicts aren't fixable.
A starting point, not an order. 'Try a heavier weight or a darker overlay' gives the designer a direction while leaving room for a fix you didn't think of.
Must fix before launch, or nice to have someday? Without priorities every note looks equally urgent, and the broken checkout waits in line behind a font opinion.
Put the four together and “make it pop” becomes: “The hero headline on the homepage (location) gets lost against the photo behind it (observation). Try a heavier weight or a darker overlay (suggestion). High priority, it's the first thing visitors see (priority).” Same instinct, but now it's a work item instead of a riddle.
You'll notice the rewrites below are longer than the originals. That's the trade: thirty extra seconds of writing buys back a whole revision round. Nobody has ever complained that feedback was too easy to act on.
12 website feedback examples, rewritten
These are the notes that show up in every inbox, every project, every industry. For each one: the vague version, why it stalls the project, and a rewrite that follows the location-observation-suggestion-priority formula. Steal the structure, not the words.
Design and visual feedback
“Make it pop.”
Why it fails: There are a hundred ways to make something pop, and the designer has to guess which one you meant. Most guesses cost a revision round.
“The hero headline gets lost against the photo behind it. Try a heavier font weight or a darker overlay on the image so the text stands out. High priority, it's the first thing visitors see.”
“I don't like the colors.”
Why it fails: Which color? Where? All of them? Nobody can act on a feeling without knowing what triggered it.
“The green on the pricing buttons sits uncomfortably close to the red we use for form errors, and at a glance they read as warnings. Could we try the darker green from the logo instead? Medium priority.”
“It doesn't feel like us.”
Why it fails: A real instinct with no handle to grab. The designer can't redesign toward a feeling they can't see.
“The layout works, but the mood reads more corporate than our brand, which leans warm and friendly. The gray section backgrounds and the stock photos are the biggest culprits. Could we try the cream background from our style guide and swap section two's photo for one from our own shoot? Medium priority.”
“Can you make it look more modern?”
Why it fails: Modern means something different to every person in the room. Without specifics, you'll get a redesign of the wrong things.
“The heavy drop shadows and gradient buttons on the service cards feel dated next to the rest of the page. Flat cards with a thin border, like the ones on the blog, would sit better. Low priority polish.”
Copy and content feedback
“The text is too small.”
Why it fails: Which text? On which page, and on what screen? Some text is supposed to be small.
“The body text in the FAQ section is noticeably smaller than the rest of the site, and it's hard to read on my laptop. Can we match the size used on the about page? Medium priority.”
“The writing needs work.”
Why it fails: It condemns every sentence on the site equally, so the writer has to defend all of them or rewrite all of them.
“The services page headline describes what we do but not why anyone should care. Something closer to 'Get your weekends back' would land better with our customers than 'Comprehensive lawn care solutions'. Happy to draft a few options. Medium priority.”
Layout and responsive feedback
“Something looks off on my phone.”
Why it fails: No device, no page, no symptom. The developer will open it on their phone, see nothing wrong, and the bug lives another week.
“On the homepage in mobile view, the menu button overlaps the logo and the first two nav links get cut off. iPhone 15, Safari. Desktop looks fine. High priority.”
“It's too cluttered.”
Why it fails: Clutter is relative. Remove the wrong things and you'll get 'where did my section go' as the next note.
“The services section shows all nine cards at once and they compete for attention. Could we show the top three and tuck the rest behind a 'See all services' link? Medium priority.”
“The spacing is weird.”
Why it fails: Weird where? Too much or too little? Spacing notes without a location send people hunting through the whole page.
“The gap between the team section and the footer is about twice the gap everywhere else, which makes the page look unfinished rather than intentional. Can we match the spacing used between the other sections? Low priority.”
Bugs, speed, and direction
“The form is broken.”
Why it fails: Which form, what did you do, and what happened? Without steps to reproduce, fixing it starts with twenty minutes of guessing.
“The 'Get a quote' button on the contact page does nothing when I click it. Chrome on desktop. The same button works fine on the homepage. High priority, this is the main thing we want visitors to do.”
“The site feels slow.”
Why it fails: The whole site, or one page? On what connection? 'Feels slow' could be images, fonts, scripts, or the reviewer's hotel wifi.
“The team page takes about six seconds to show the photos on my phone, on wifi. Every other page loads fast for me. Could those images be compressed? High priority before launch.”
“I liked the old version better.”
Why it fails: It rejects everything at once, including the parts everyone agreed on. Morale drops, and nobody knows what to restore.
“Version 3 moved the testimonials below the pricing table. I think they did more work above it, where hesitant visitors read them before seeing the price. Can we move them back up and keep everything else from v3? Medium priority.”
How to give design feedback when you're not a designer
Most people who comment on website design aren't designers, and that's fine. You don't need design vocabulary to give great design feedback. You need a few habits.
Describe the problem, not just your solution
“Make the logo bigger” is a solution. The actual problem might be that the logo is hard to read, which a designer could fix with contrast or spacing instead of size. Lead with what's bothering you, then offer your idea as one option. You'll often get a better fix than the one you asked for.
Anchor every note to what the page is for
“This page should make people call us, and the phone number is the smallest thing on it” is feedback a designer can defend in their own head. Taste arguments go in circles. Goal arguments resolve.
One note per issue
A paragraph that bundles five problems gets answered as one, and three of the five quietly fall through. Separate notes can be separately discussed, separately fixed, and separately checked off.
Say what works, too
Not as a courtesy sandwich. If you only flag problems, the designer has no idea which parts are safe, and the thing you loved might get redesigned away in round two. “Keep the hero exactly as it is” is feedback.
Point at the thing
The single biggest upgrade. Feedback that lives in an email has to describe where it's pointing; feedback that lives on the page just points. If you're the designer on the receiving end of vague notes, this is the habit worth engineering into your process. (We wrote up how that works for web designers running revision rounds.)
How to review a website, step by step
Good individual notes still get lost if the review round itself is chaos. Here's a simple structure that works whether you're a client reviewing an agency's work or a team reviewing its own.
- 1Review the real thing
Open the live or staging URL, not a PDF of screenshots. Screenshots hide hover states, animations, load times, and everything that happens when you actually click.
- 2Do one pass per device
Desktop, tablet, and phone are three different websites wearing the same domain. Walk each one separately and keep the notes separate, so 'broken on mobile' never gets tested on a desktop monitor.
- 3Click around, don't just scroll
Open the menu, submit the form, follow the links, play the video. Half of the most expensive bugs are invisible until something gets clicked.
- 4Leave each note where the problem lives
On the page, attached to the element, with the location handled by the pin instead of by prose. One place for every comment, one thread per issue.
- 5Triage before anyone starts fixing
Sort everything into must-fix and nice-to-have before work begins. Ten minutes of triage protects days of build time from being spent on the wrong notes.
- 6Resolve as you go, then close the round
Every fixed item gets marked resolved, so the list only ever shrinks. When it hits zero, the round is over. No 'wait, did we ever fix the footer?' three weeks later.
This is, not coincidentally, the workflow Pin Feed is built around: one share link opens the real site, reviewers join with just a name and an email, each of the three viewports keeps its own pins, every pin auto-captures a screenshot of the page at that moment, and threads get resolved one by one until the round is done.
The takeaway
Vague feedback isn't a character flaw, it's a missing format. Give people the four-part structure (location, observation, suggestion, priority), show them an example or two, and the quality of every review round jumps. Give them a tool that handles the location part automatically and it jumps again.
Next time a “make it pop” lands in your inbox, don't roll your eyes. Reply with one question: “Which part, and what's it doing wrong?” You're one answer away from a note you can actually build.