How to give website feedback that gets acted on (a guide for clients)

You’ve been sent a link to review a new website. Maybe it’s your company’s site, maybe it’s a campaign page, maybe it’s a redesign you’ve been waiting months for. Either way, the team that built it is waiting for your feedback — and the quality of that feedback decides how quickly the site goes live.

This guide is written for you, the reviewer. You don’t need to know anything about design or code. You just need to know how to describe what you see in a way the team can act on. Feel free to forward it to anyone else reviewing with you.

Why good feedback matters

Every unclear comment becomes a conversation. “The top bit looks weird” leads to “Which top bit?”, then “On which page?”, then “What looks weird about it?” Three emails later, the team finally understands — and a day has gone by.

Clear feedback cuts that out. It also means you get what you actually wanted, instead of the team’s best guess at what you meant.

The good news: clear feedback follows a simple pattern, and once you know it, it’s quicker to write than vague feedback.

The four parts of a useful comment

A comment that gets fixed first time usually answers four questions:

Where? Which page, and which exact part of it.
What? What you see right now.
What instead? What you expected or would like.
Why? (optional) The reason, if it helps the team make the right call.

Here’s that pattern in action.

Vague: “The contact section needs work.”

Clear: “On the Contact page, the phone number in the footer is our old number. It should be 020 7946 0123.”

Vague: “Can the images be better?”

Clear: “On the About page, the team photo is blurry when I look at it on my laptop. Do we have a higher-resolution version?”

Vague: “I don’t like the button.”

Clear: “On the homepage, the ‘Book a demo’ button is grey, so it doesn’t stand out. Could it be our brand orange so people notice it?”

Notice that the clear versions aren’t longer by much — they’re just specific.

1. Point at the exact thing

Location is the most common source of confusion. Words like “the top”, “the second box” or “the image on the right” change meaning depending on screen size.

If you’ve been sent a review link where you can click directly on the page to leave a comment, use it — click the actual element you’re talking about, and your comment will be attached to it. Many teams use tools like this (ClientTweak works this way: you open the link, click the element, and type, with no account needed).

If you’re sending feedback by email or in a document instead:

Include the page address (copy it from the browser’s address bar).
Take a screenshot and draw a circle or arrow on the part you mean.
Quote any text you’re referring to, so it can be searched for.

2. One comment per issue

It’s tempting to write everything about a page in one long comment. Please don’t. The team will usually split your feedback into separate tasks, and things get lost in the splitting.

Hard to act on:

“Homepage: the headline should be shorter, the photo should be of our office, I think the testimonials need more space, and the price in the second box is wrong.”

Easy to act on (four separate comments):

“Headline: can we shorten this to ‘Accounting for growing businesses’?”

“Hero photo: please swap for one of our office — I’ll send three options.”

“Testimonials: these feel cramped. Can they have more space between them?”

“Pricing box 2: the Standard plan is £49/month, not £45.”

Four comments take the same time to write, and each one can be fixed, checked and closed on its own.

3. Describe what you see, then what you want

Designers and developers are good at solving problems. They’re less good at reading minds. Describe the problem as well as the solution you have in mind — sometimes there’s a better fix you haven’t thought of.

Instead of…	Try…
“Make the logo bigger.”	“The logo is hard to see on my phone. Can it be bigger, or is there another way to make it stand out?”
“Change the font.”	“The body text feels small and hard to read on my laptop.”
“Move this up.”	“Most people won’t scroll this far. The booking form is the main thing we want them to do.”
“It’s broken.”	“When I click ‘Submit’ on the contact form, nothing happens. I’m on an iPhone using Safari.”

4. Say what kind of feedback it is

Not all feedback is equal, and the team needs to know which is which. Three useful labels:

Must fix: wrong information, broken links, things that don’t work, legal requirements. These block launch.
Should fix: things that look wrong or don’t match what was agreed.
Nice to have / preference: your personal taste, or new ideas.

Preferences are welcome — just say they’re preferences. “Personally I’d prefer a warmer colour here, but happy to go with your recommendation” helps the team prioritise and keeps the project on budget.

If your review tool lets you set a priority, use it. If not, start your comment with [Must fix] or [Preference].

5. Tell the team what you were using

If something looks wrong or doesn’t work, it might only happen on certain devices. Add a quick note:

Device: laptop, desktop, phone or tablet (and which model, if you know)
Browser: Chrome, Safari, Edge, Firefox
What you did: “I clicked the menu, then clicked ‘Services’”

That one line can save an hour of the team trying to reproduce the problem.

6. Review the whole page, not just the first screen

It’s natural to spend most of your time on the part of the page you see first. Scroll all the way down every page in scope, including:

The footer (addresses, links, social icons, copyright year)
Forms (try submitting one)
Menus on your phone
Pages you don’t visit often, like the privacy policy or a “thank you” page

If you’re short on time, ask the team which pages matter most and start there.

7. Gather feedback from your colleagues first

If several people at your company are reviewing, the biggest favour you can do the team is to agree internally first. Conflicting comments (“make it bigger” from one person, “make it smaller” from another) are common, and the team can’t decide between them for you.

Two ways to handle it:

Nominate one person to collect everyone’s comments and send a single, agreed set of feedback.
Review in the same place so everyone can see each other’s comments and reply in the thread instead of contradicting each other.

8. Stick to the scope of the round

Teams often run reviews in rounds: content first, then design, then final checks. If you’ve been asked to review the copy this round, a comment about changing the whole layout might be out of scope — and could reset the project timeline.

New ideas are still valuable. Just label them: “Idea for later — not urgent.”

9. Reply when the team responds

If the team asks a question on your comment, answering quickly keeps things moving. And when something has been fixed, take a look and confirm. A quick “Looks great, thanks” lets them close the item and move on.

A quick template you can copy

If you’re writing feedback in an email or document, this template keeps every comment clear:

Page: (address or page name)
Where: (which part of the page — or attach a screenshot)
What I see: 
What I'd like instead: 
Priority: Must fix / Should fix / Preference
Device and browser: (if something looks wrong or doesn't work)

Common mistakes to avoid

“Can you make it pop?” — say what you want to stand out and why.
Feedback on a screenshot from three versions ago — always review the latest link you’ve been sent.
Sending comments across email, chat and phone calls — keep them in one place so nothing is missed.
Rewriting copy in your head but not on the page — if you want different wording, write the exact words you want.
Saying “fine” when you’re not sure — it’s much cheaper to raise a doubt now than after launch.

The short version

Point at the exact thing. One issue per comment. Say what you see and what you want. Mark what must be fixed. Note your device if something’s broken.

Do that, and your website will go live faster — looking the way you actually wanted it to.