How to Leave Feedback on a Website Design (A Client Guide)

Someone has sent you a link to a website design and asked what you think. Maybe it is a staging URL, maybe a mockup, maybe a shared prototype. Either way you are now supposed to leave feedback on a website design, and there is a decent chance nobody told you how.

Reviewing a website is not the same as reviewing a poster or a logo. A website changes shape depending on the screen. Parts of it are interactive. Some of what you are looking at is placeholder content that was never meant to be final. Feedback that would be perfectly clear on a static image ("move the headline down a bit") can be meaningless on a page that reflows differently on every device.

This guide covers what to actually look at, how to say where you mean, and what to skip. It applies whether you are reviewing in a browser, a shared file, or a dedicated design feedback tool. It is written for the person doing the reviewing, and it is short enough to send to a client before you share a link.

First, find out what stage this is

Before you write a single note, ask one question: what is this, and what is it not?

The answer changes everything about what useful feedback looks like.

A wireframe or low-fidelity layout. Structure only. Comments about colour, fonts, and photography are premature, because none of those decisions have been made yet. Focus on whether the right things are on the page in the right order.
A visual design or mockup. Look and feel is now fair game. Interaction may still be faked.
A built staging site. Everything is in play, including behaviour: hovers, forms, menus, load speed, and how it holds up on a phone.
A live site being revised. Same as staging, but changes carry more risk, so be specific about priority.

If nobody told you which of these you are looking at, ask. Two minutes of clarification saves a round of feedback aimed at the wrong layer.

The second thing worth confirming is whether the content is real. A remarkable amount of review time gets spent on placeholder text and stock photos that were always going to be replaced. If the copy says Lorem ipsum or the team photo is obviously a stock image, skip it unless the length of the text is causing a layout problem — that part is genuinely useful to flag.

What to actually check on a website design

Working through the page in a fixed order beats scrolling and reacting. You catch more, and you avoid the trap of writing eleven notes about the hero section and none about the rest of the site.

Does the page tell you what this is within a few seconds? Land on it fresh and read only what is above the fold. Can you say what the company does and what you are supposed to do next? If not, that is the single highest-value note you can leave, and it outranks every colour preference you have.

Is the hierarchy right? The biggest, boldest thing on the screen should be the most important thing on the page. If your eye lands on a decorative image before it finds the headline, say so.

Can you find what you came for? Pick two or three realistic tasks — find pricing, find contact details, find out whether they serve your region — and try to do them. Note where you hesitate. Hesitation is data.

Check it on a phone. Most traffic is mobile, and most feedback is written on a desktop. Open the same link on your phone and scroll the whole thing. Long headlines wrap badly, tables overflow, and buttons end up under thumbs. This is where a lot of genuinely useful feedback comes from and where almost nobody looks.

Try the interactive bits. Click the navigation. Open the menu. Start filling in the form. Hover the buttons. On a staging site these often reveal more problems than the static layout does.

Read the actual words. Headlines, button labels, error messages. "Submit" versus "Get my quote" is a design decision, not a copywriting afterthought, and reviewers routinely skip past it.

Then, and only then, look at the styling. Colour, spacing, type, imagery. This is the part everyone starts with, which is exactly why it should come last.

Say where you mean, precisely

This is where most website feedback falls apart. Not because the reviewer is wrong, but because the designer cannot tell what they are pointing at.

Consider a real note: "The button near the top doesn't stand out enough." On a page with a sticky header, a hero, and an announcement bar, there might be four buttons near the top. The designer now has to guess, and roughly half the time they guess wrong and you get a revision that fixes nothing.

Three ways to remove the ambiguity, in rough order of how well they work:

Pin the comment to the element. If you have been sent a link to a review tool, click directly on the thing you mean and type there. The note and the location travel together and no description is needed.
Quote the visible text. "The Book a consultation button in the hero" is unambiguous even in an email, because there is only one element with that label.
Screenshot and mark it up. Slower, and it goes stale as soon as the design changes, but far better than a written description of a location.

If you are leaving feedback on a live or staging website specifically, also say which page and which screen size. "On the pricing page, on mobile" is three words that save a round trip. A website feedback tool handles this automatically by recording the page and viewport alongside each comment, which is largely why they exist.

Describe the problem, not the fix

The most common failure in design feedback is not vagueness. It is jumping straight to a solution.

"Make the logo bigger" is a prescription. The underlying problem might be that the brand feels absent from the page, that the header looks unbalanced, or that the logo reads as decoration rather than identity. Each has a different best fix, and enlarging the logo is only one of them — sometimes the worst one.

Try to say three things: what you noticed, where, and why it bothers you.

Instead of: Make the headline bigger.

Try: On the homepage hero, the headline doesn't feel like the main message — the background photo pulls my eye first.

The second version gives the designer a problem to solve with their actual expertise. You are far more likely to get something that works, and you have not accidentally taken responsibility for a design decision you did not want to own.

This holds for positive feedback too. "Love it" is pleasant and useless. "The way the case studies are laid out makes it easy to skim" tells the designer what to protect in the next round.

Send your website design feedback once, not in six messages

Feedback that arrives in five separate messages over three days is not five times more helpful than one consolidated round. It is worse, because the designer starts working on note one before notes four and five arrive and contradict it.

Write everything down as you review, then send it as one batch. If something genuinely urgent comes up later, send it, but label it as an addition rather than dropping it into the same undifferentiated stream.

While you are consolidating, do two more things:

Resolve internal disagreements first. If three people on your side are reviewing, do not send the designer three conflicting opinions and let them referee. Agree internally, then send one voice. Contradictory client feedback is one of the most reliable causes of wasted revision rounds.

Mark what matters. Not every note is equal. Flag the two or three things that genuinely need to change before launch, and mark the rest as minor. Without that, everything reads as equally urgent, and the important notes get the same weight as a two-pixel spacing preference.

Say clearly whether it is approved

A pile of comments is not a decision. Designers routinely finish a round of feedback with no idea whether they are cleared to build or still iterating, because the reviewer left eight notes and never said what happens after they are addressed.

End every round of feedback with one explicit sentence. Either:

Approved — go ahead and build it, or
Approved once these three things are fixed, or
Not yet — here's what needs to change first.

That sentence is worth more than the eight notes above it. It is also the thing an explicit approval step exists to capture, so that "the client approved version 2 on the 4th" is a recorded fact rather than a disputed memory. Both sides benefit from that: the designer knows where the boundary is, and the client knows exactly what they signed off on.

How Aligno fits into website review

If you are the designer on the other side of this, most of the friction above is structural rather than a client problem. Feedback is vague because email gives clients no way to point at anything.

Aligno gives you a share link for a live webpage or a design file. Your client opens it, clicks the exact spot they mean, types the note there, and records a clear approve or request-changes decision at the end. There is no account to create and nothing to install on their side, which matters because the review only helps if the client actually does it. There is also a free website annotation tool if you just want to try the pinning workflow on a page before signing up for anything.

Frequently asked questions

How do I leave feedback on a website design?

Review the page in a fixed order — message, hierarchy, navigation, mobile, interaction, copy, then styling — and write each note as what you noticed, where, and why. Point at elements precisely by pinning the comment directly on the design or by quoting the visible text, then send everything as one consolidated round with a clear approve or not-approved decision at the end.

What should I look for when reviewing a website design?

Start with whether the page communicates what the business does within a few seconds, then check that the visual hierarchy matches the actual priorities, that you can complete two or three realistic tasks without hesitating, and that it holds up on a phone. Leave colour and spacing preferences for last — they are the easiest to notice and usually the least important.

How do I give website feedback without sounding rude?

Describe the problem rather than criticising the work, and be specific about your reasoning. "The headline doesn't stand out against the background photo" reads as a useful observation, while "the hero looks bad" reads as a judgement. Naming what is working, briefly and genuinely, also makes the critical notes easier to hear.

Should I say how to fix it or just what's wrong?

Describe what is wrong and why it bothers you, and leave the fix to the designer. Prescribing a solution ("make the logo bigger") hides the underlying problem, and the fix you suggest is often not the best available one. If you have a specific idea, offer it as one option rather than as the instruction.

How much feedback is too much on a website design?

The problem is rarely the number of notes, it is that they arrive unprioritised and in several batches. Send one consolidated round, flag the two or three items that must change before launch, and mark the rest as minor. Fifty notes with clear priorities are easier to act on than twelve that all read as equally urgent.

Aligno turns website review into one share link: your client pins feedback on the exact spot and gives a clear yes or a specific list of changes, with no account to create. Try it free.