A clearer way to collect client feedback

A review round goes wrong when people are answering different questions about different versions. One person is choosing a direction, another is correcting a detail and a third is commenting on a file that has already changed. The project owner then has to interpret the discussion before doing the actual work. A clearer process starts before the review link is sent: define the decision, identify who can make it and show everyone the same version.

Write the question the review must answer

“Thoughts?” is a difficult brief because it offers no boundary. For a concept review, ask which direction best fits the agreed audience and why. For a production review, ask whether the approved content and dimensions are correct. For final signoff, state exactly what the client is approving. Each question calls for different evidence and a different level of attention. Keeping those rounds separate gives the team a better chance of receiving useful feedback.

Put the question at the top of the invitation. Include a sentence about what is outside the round, such as copy that has already been approved or a color choice being tested separately. This helps reviewers use their time on the decision the project needs now. It also gives the project owner a clear way to route a new request without losing it inside the current discussion.

Name one person who closes the round

Several people may need to comment, but someone must decide what happens next. The decision owner should know which colleagues to consult and how disagreements will be resolved. A project owner cannot reliably infer approval from silence or from a collection of positive comments. Ask for an explicit decision once the review is complete, with any conditions written down beside it.

An illustrative packaging project might involve a brand lead, a product manager and a technical specialist. The brand lead selects the direction. The product manager verifies the required content. The technical specialist checks the production constraints. Those responsibilities overlap in conversation, but they should remain distinguishable in the record. If the technical check is incomplete, the direction can be selected without pretending that production approval has also happened.

Give versions ordinary, stable names

A version label should make sense when copied into an email or spoken on a call. Use a project name, a version identifier and a date where useful. Avoid a chain of filenames that all say final. The review page should display the same identifier as the source file, and a later version should not quietly replace the artifact attached to an earlier decision.

Keep one obvious current review link. If an old link remains accessible, show which version it contains and where the current review lives. The point is to preserve history without making the reviewer choose among several apparently valid files. When a project changes direction, the record should explain the decision that caused the change rather than rely on someone remembering the meeting.

Attach each comment to a target

A useful comment identifies the place, the issue and the desired outcome. “The delivery line is hard to find on the side panel; could it sit closer to the product quantity?” gives a designer something to examine. “Make it pop” transfers the interpretation work without explaining the problem. Ask reviewers to describe what they are trying to achieve, especially when they propose a visual solution.

The W3C Web Annotation Data Model distinguishes an annotation's body from its target. That is a useful way to think about everyday review tools: preserve both what someone said and the part of the work they were discussing. A screen coordinate alone can become confusing after the layout moves. A text quote, a page label or a time range provides additional context when the team returns to the comment later.

Make the review request accessible

Reviewers need instructions they can find again after opening the work. Put the due date, the decision question and the submission action in visible text. A comment box needs a persistent label. Error messages should explain what the reviewer needs to change. The W3C guidance on form instructions explains why placeholder text is not a substitute for labels and how instructions help people complete inputs.

Try the process using only a keyboard, including opening the artifact, finding the instructions and submitting a response. If the team shares a video, provide the context needed to discuss a particular moment. If it shares an image, include a readable description of the decision being requested. A reviewer should not have to decode an unfamiliar interface before reaching the creative question.

Turn the discussion into a decision log

At the end of the round, write a short decision record. Include the version reviewed, the approved direction, the required changes, unresolved questions and the next owner. This is the bridge between feedback and execution. It should be brief enough to read before starting the next revision, while retaining enough detail to explain why the work changed.

For the packaging example, the log might say that direction B is selected, the delivery information must move nearer the quantity and the technical specialist will confirm the print area before production. That is more useful than closing all comments and marking the project complete. The decision log makes the remaining work visible without asking every participant to reread the full conversation.

Handle late feedback explicitly

A late request can be valid and still affect the plan. Acknowledge it, identify whether it changes an approved decision and show who needs to authorize the change. The project owner can then explain the effect on the next review or production step. Treating every late comment as an immediate instruction makes the approval process hard to trust.

Keep a place for useful ideas that belong in a later round. That lets a reviewer contribute without turning the current deadline into an open-ended redesign. The distinction should be visible: required for this release, proposed for a later release or awaiting a decision. Plain words work better here than a complicated scoring system that only the project manager understands.

Prepare the next invitation in one page

Before the next review, write a page with the project name, the current version, the decision question, the decision owner, the closing date and the feedback format. Add one example of a useful comment and explain how the result will be recorded. Then send it with the actual work. This is a small change that can be tested on one round without replacing every tool the team already uses.

Afterward, ask where reviewers needed clarification and which comments required interpretation. Use those observations to revise the next brief. A good review process becomes easier to follow as the team learns, and the decision record becomes part of the project rather than a separate administrative chore.