Useful website feedback gives the person making the change enough context to act and the person approving it a clear way to check the result. Before launch, we recommend including four things in every note: the page, what you observed, the change you want, and who can make the final decision.
You do not need design vocabulary to do this well. You need to explain what a visitor should understand or be able to do. A comment such as “the homepage feels off” starts a conversation; a note that identifies an unclear headline and its intended meaning can move a revision forward.
Agree on who reviews and who decides
Before sending the preview around, name one person to collect the business's feedback and one person with authority to approve the combined requests. In a small business, that may be the same person. Other reviewers can contribute expertise without each sending competing instructions to the website team.
Give everyone the same current preview link and a clear review deadline. State what is ready for review: page wording, navigation, imagery, or the full working site. If a section is still awaiting approved content, label it so reviewers know its status.
We suggest keeping comments in one shared list. A document, spreadsheet, or the team's existing review tool can work. The useful part is that each issue has its own entry and everyone can see the latest decision. When feedback arrives by email or in a meeting, the coordinator adds it to that list before it becomes a revision request.
Use four fields for every feedback note
- 1Page and location: Include the preview URL and the heading, button label, or section involved. For a display or interaction issue, add the device and browser you used.
- 2Observed issue: Describe what you saw or what happened. If you clicked something, include the steps and the actual result. Explain why it matters for a visitor.
- 3Desired change: State the intended meaning or behavior. Supply exact replacement wording when the wording is a business decision; ask the website team to recommend a solution when you are unsure.
- 4Decision owner: Name the person who can settle the request and accept the result. If someone else must confirm a business fact first, record that dependency.
Add a screenshot when location or appearance is hard to describe. Mark the relevant area and keep enough surrounding context to identify it. Put the explanation in the written note as well, so a screenshot does not have to carry the whole request. Remove customer details or other sensitive information before sharing a capture.
For an issue that comes and goes, say how often you noticed it and what you tried. “It happened twice after opening the menu on my phone” is more useful than guessing at a technical cause. You can report the behavior without diagnosing the code.
A worked example: make the request checkable
The following is a hypothetical example, not a description of a client project. Imagine a service business reviewing the introduction to its website.
The first note reads: “Make the top section more professional.” That could mean different wording, a different image, less content, or a different layout. The website team cannot tell which outcome the business wants.
- Page and location: The homepage in the current preview, opening heading and paragraph above the first button.
- Observed issue: The heading says “Solutions that work,” and the paragraph never names our service. I cannot tell from this section that the business provides commercial cleaning.
- Desired change: Replace the heading with “Commercial cleaning for offices” and rewrite the paragraph to explain the service in plain language. Keep the existing button destination.
- Decision owner: The business owner confirms that this service description is accurate and approves the revised wording.
The team now has a specific meaning to communicate and a boundary to preserve. The owner can check the revised preview by asking whether that opening section clearly names the service. Any additional service claim still needs confirmation before it is added.
The same format works for behavior. In another hypothetical example: “On the Services page in the mobile preview, I open the menu and select About, but the menu stays over the page. Please make the menu close after a selection so I can read the destination. Our project lead will verify the change on the same device.” Add the actual device, browser, preview link, and screenshot to make that report reproducible.
Separate an observation from a preferred solution
A visual preference is useful feedback when it is connected to the page's purpose. “Make this button bigger” names one possible solution. “I had trouble finding the next step after reading the service description” explains the difficulty the design needs to address. Include both if you have a preference, and make clear which part is the required outcome.
We recommend writing what needs to stay, too. For example, a hypothetical note might say: “Shorten this introduction so the service list is easier to reach, while keeping the approved service-area sentence.” That prevents a well-intended edit from removing information the business needs.
For text changes, give one approved replacement rather than several competing rewrites. For imagery, explain the relevant problem, such as showing the wrong type of service. Supply an approved image if you have one, or identify what needs approval before a replacement can be chosen.
Resolve contradictory requests before assigning the work
Suppose one reviewer wants every service listed on the homepage and another wants the homepage shortened. Both may be responding to a real concern. Forwarding both comments as instructions leaves the website team to make an unresolved business decision.
The coordinator should bring the conflict to the decision owner with the reason behind each request. Ask which visitor task takes priority on that page and what detail can live elsewhere. The team can explain design implications, but the authorized business owner needs to settle the business priority.
A hypothetical final decision could be: “Keep short summaries of the three approved service categories on the homepage. Put the detailed descriptions on their service pages. The owner has approved this direction.” Record that decision beside the original comments and mark them as replaced by the agreed request.
Keep unresolved items visibly marked as awaiting a decision. If an approved direction changes later, identify the earlier decision it replaces and ask the team to assess the effect on scope and timing before proceeding. A fresh message should not silently overrule the shared list.
Tell the team what must be resolved before launch
We suggest giving each agreed request a simple priority and a reason. An incorrect service claim or a navigation problem needs a different discussion from a preference about the shape of an illustration.
- Must resolve before launch: Explain the consequence, such as inaccurate business information or a visitor being unable to complete an essential task. Agree on the fix and who will check it.
- Decision needed: Identify the missing choice, its owner, and when it is needed. Make clear whether that decision blocks launch.
- Can follow after launch: Record the accepted limitation, the person responsible, and a planned follow-up. Confirm this explicitly with the decision owner.
Ask the website team to flag changes that add new pages, features, or substantial content work. Review their scope and timing before approving them. Clear feedback can still be a new request; writing it clearly does not make it part of an existing agreement.
Close each request against the revised preview
When revisions are ready, review the version the team identifies. Check each item against its recorded desired outcome. Mark it accepted, still needs work, or awaiting a decision. If it still needs work, describe the remaining gap in the same entry instead of starting a disconnected conversation.
Keep new observations separate from the check on a completed request, and link related items. If a revision introduces a new problem, explain that connection. This helps everyone see whether an earlier request was missed, misunderstood, or completed and followed by a new requirement.
Finally, record who reviewed the current version, which issues remain, and who can authorize launch. Acceptance of a single wording or layout change does not by itself authorize publication. The person responsible for launch should give explicit approval for the agreed version.
For the wider project context, see our guide to the web development process from kickoff to launch. For your next feedback round, start with one shared list and rewrite the first unclear comment into four fields: page, observation, desired change, and decision owner.