Give Website Feedback a Developer Can Act On

"Make the website easier to use" may be an honest response to a frustrating page, but it leaves a developer guessing. Easier for whom? Which task is difficult? Are you asking for a new design or for the booking button to stop disappearing on your phone?

You don't need technical vocabulary to give useful feedback. You need a specific observation, a reason it matters, and a way to recognize a successful change. That is usually faster than collecting another round of screenshots with arrows and no explanation.

Review the customer journey before the design

Choose a task a visitor should be able to finish: finding your service area, requesting an estimate, or viewing a photography package. Start where that person would arrive and follow the links yourself. Test the path on your phone as well as your computer.

Make a short page list with each page's purpose and its next action. A contact page buried beneath unrelated links needs a different fix from a broken form. This review may reveal that you need a clearer label or a missing link, rather than an expensive redesign.

Keep observations separate from proposed solutions. "I couldn't find the session length" is evidence from your review. "We need a pop-up" is a suggestion. A developer or designer may have a better answer once they understand the problem.

Write a request someone else can reproduce

Give each issue its own request. Combining a font change, a checkout problem, and a new service page in one paragraph makes estimates and approvals harder. Use these fields in an email, shared document, or task board:

• Exact page URL and the section, link, or field involved.
• Device and browser, plus whether you were signed in. Include the screen width if you know it.
• Steps taken and what currently happens.
• What you expected to happen and why that matters to the visitor.
• A screenshot or short recording, with private information removed.
• Acceptance criteria: the checks you and the developer will use to call the work complete.
• Priority, owner, and any genuine deadline.

Quote the visible button text rather than calling it "the green one." Add the date of your observation if the website changes often. If you can't reproduce the issue every time, say so and describe when it appeared. Don't turn an intermittent problem into a confident diagnosis.

Example: a photography inquiry form

Imagine a portrait photographer reviewing a staging website. This is a hypothetical request, not a report about a customer's site.

Page: the portrait inquiry page. Environment: an iPhone using Safari, signed out. Steps: open the page, choose a session type, and submit with the required email field empty. Current behavior: the page stays still and I can't tell why the request failed. Expected behavior: show an understandable error next to the email field and help me reach it. Visitors shouldn't have to guess which field needs attention.

The photographer and developer could agree that the change is complete when an empty email field produces a visible, meaningful error; keyboard users can reach the field; correcting the email allows the test request to proceed; and other required fields still behave correctly. The developer should check accessibility details and any existing form rules, rather than applying a visual patch alone.

The request should also name a safe test destination. A successful-looking confirmation page doesn't prove the inquiry arrived. Use clearly marked test details, verify receipt in the agreed inbox, and avoid creating a real booking or sending messages to an unsuspecting customer.

Sort faults from preferences

A broken inquiry path deserves attention before a debate about background colors. Group requests into blocked customer tasks, confusing but usable behavior, and optional presentation changes. Explain business impact without inventing lost-sales figures you haven't measured.

For visual work, attach a reference and explain what you like about it. "Use this spacing between service cards" gives direction. "Make it look premium" could mean almost anything. Agree whether the work covers one page or a shared component used across the site.

Ask the developer to flag related risks before starting. A navigation change may affect existing links, mobile menus, or pages outside your original request. Record any expanded scope separately so it doesn't disappear into an informal approval.

Use visual tools without confusing review with editing

SiteGraph is one of our DVGProOS tools. Its website mapping and annotation workflow describes visual page maps, feedback pins, and structured change requests. Crawling and live preview are read-only: SiteGraph does not edit your website. A request still needs implementation and testing by your team or an appropriate development workflow.

If you prefer a simpler setup, keep a page list in a spreadsheet and put numbered annotations on screenshots. The useful part is the connection between the exact location, the observed problem, and the agreed result. More pins won't rescue an unclear request.

Close the request with evidence

When a change is ready, repeat the original steps in the agreed test environment. Check the acceptance criteria, then try the nearby path a customer might take. Record what you tested and any remaining issue. Approving a staging preview and authorizing a live release should be distinct decisions.

Choose one frustrating page today and write one complete request. You can discuss the rest of the redesign after you and your developer have agreed what that first fix needs to accomplish.