How to give website feedback a developer can act on

Useful feedback names the page, the problem and the desired outcome. You do not need to prescribe the code, but the developer should be able to understand what needs changing without guessing.

Choose one feedback owner

Collect comments from stakeholders, resolve disagreements and send one list. If two people request opposite changes, decide before sending them. State which preview version the comments refer to so later checks use the same starting point.

Describe the customer consequence

Replace “The page feels wrong” with “On mobile, the heading covers the image and the service name is hard to read.” Replace “Make it pop” with a clear priority: “The enquiry link should be easier to locate after the service explanation.” This leaves room for the developer to propose a suitable design fix.

Use a repeatable item format

Separate corrections from additions

A misspelled service name is a correction. Adding a booking system after agreeing an email-only route is a scope change. Mark each type openly and ask for the effect on price and schedule before approving additional work. This prevents revision rounds being used to quietly redefine the project.

Check the response

Ask the developer to mark each item resolved, explained or awaiting a decision. Review the changed page on the relevant device. If the result still misses the goal, explain the remaining problem instead of simply repeating the original comment.

Keep the final list with the acceptance record. It shows what was requested and what was approved. For a package with limited feedback rounds, agree how a round is collected and when it closes. Clear feedback helps both sides finish a defined project; it does not require pretending every opinion is equally urgent.

Practical guidance with illustrative examples. Read our editorial standards or send a correction.