How do I give useful website design feedback?

The designer sends the first screens. You can tell something isn't right, but "make it more premium" feels like the only way to explain it. The next version looks different and still misses the point.

Useful feedback names the thing that stops the page doing its job. You can give that feedback without choosing fonts, moving boxes or knowing the technical language.

What should you judge the design against?

Start with the purpose agreed for this page.

Useful website design feedback connects a visible detail to a buyer's task or an agreed requirement. It tells the designer what isn't working and why, while leaving room to choose a good solution.

Keep the brief beside the design. Who is the page for, what do they need to understand and what should they do next? A visual preference can matter, but it shouldn't be the only test.

For a hypothetical engineering consultancy, "I can't tell which service handles an existing building" identifies a useful problem. "Make the cards more modern" doesn't explain what the buyer needs.

If your team cannot agree what the offer should communicate, settle that first. The homepage clarity test can help identify a message problem that another colour scheme won't resolve.

How do you make a comment actionable?

Point to the detail, explain the effect and state the intended result.

Give enough context that the designer doesn't have to guess the concern.

Vague comment	More useful feedback
It feels busy	The announcement, headline and two bright buttons compete; I need the service and enquiry action to lead
Make it premium	The reference we approved uses calmer type and fewer decorative elements; this version feels closer to a discount advert
This photo is wrong	It shows residential work, but this page sells commercial inspections
Make the button bigger	On the phone screen I miss the enquiry action after reading the service summary

The revised comments give the designer a problem to solve. They don't require you to decide the exact dimensions or type style.

Where possible, mark the relevant section on the shared screen or attach an annotated image. Include the page and screen size so the feedback stays connected to the right version.

Is it a preference, a usability problem or new scope?

Label the kind of decision you're asking for.

A preference might be that a serif typeface doesn't suit your brand. A usability problem might be that the text is difficult to read against its image. A scope change might be a request for an interactive calculator that wasn't included in the brief.

All three can deserve attention, but they need different conversations. A new feature isn't simply another visual revision.

If something is a personal preference, say so and explain the brand context. If it's a suspected usability problem, describe the task and evidence rather than presenting your guess as a measured result.

Ask how a new request affects the work before treating it as part of the current round. Our website budget guide explains why functionality and content responsibility belong in the scope.

What should you check before approving a screen?

Review the real content and important states, not just the cleanest screenshot.

Look at the full page on a suitable screen and the proposed mobile version. Check the actual service names, representative text lengths and images you expect to use.

Ask where the primary action leads, what an error looks like and whether long content fits. If a section will be editable, ask what happens when an optional image is missing or the headline becomes longer.

Our guide to editing without breaking the page shows why those content examples should influence the design before the build.

Don't judge a mobile screen only as a tiny picture inside a desktop presentation. Inspect it at a readable size and consider the task with the phone keyboard or menu open where relevant.

If you want the design decisions and the finished website handled together, we can design the screens before building them in custom code. We agree the scope and review the designs with you, so the finished website follows an approved direction. Start with a free intro call, or send the project context to hi@aruno.studio, WhatsApp or Telegram @mihaipostelnicu.

How should a team collect its feedback?

Send one coherent set of decisions instead of several conflicting threads.

Let everyone inspect the same version. Ask them to connect comments to the brief, then resolve contradictory requests internally where possible. One person should be able to say which decision the designer should follow.

Group comments by page or section and indicate priority. Separate an approval blocker from a small preference. Include questions when you need the designer to explain a decision rather than immediately replace it.

For example:

On the services screen, buyers need to distinguish a survey from ongoing project support. Both cards currently use the same heading and image. Please make that difference clear. The exact card layout can change if it helps.

That is a more complete instruction than six comments asking for different card colours.

How do you know the revision addressed the feedback?

Check the original problem again, not only whether the screen changed.

If the issue was an unclear service distinction, ask whether someone can now choose the correct route. If it was readability, inspect the revised text at the intended size.

Keep a short record of approved screens and unresolved points. Once the website is built, use the separate design-versus-live-site checks to assess whether the agreed decisions were carried through.

A new visual treatment isn't automatically a successful revision. The test is whether the concern you named has been resolved.

Frequently asked questions

Do I need to know design terminology? No. Point to what you see and explain what it prevents the visitor from understanding or doing. The designer can translate that into a visual decision.

Can I say that I simply don't like something? Yes. Taste and brand direction matter. Explain which quality feels wrong and refer to the agreed direction, rather than inventing a usability claim to justify a preference.

How many feedback rounds should there be? That belongs in the project agreement. Check what each round covers and how additional requests are handled instead of assuming unlimited redesigns.

How quickly should I send feedback? Within the review window agreed in the project plan. If you need more time, say so early, because late comments usually move the next round and the launch date with them.

Should I approve desktop before seeing mobile? You can review work in stages, but don't leave important mobile decisions undefined. Agree when mobile layouts and interactions will be shown before development depends on them.

Replace one vague comment with the detail, its effect and the intended result. The next revision will have a much clearer target.