How to comment and give feedback
Leave useful, specific feedback directly on the relevant deliverable.
Good feedback saves a round. The aim is to be specific enough that the team can act without coming back to ask what you meant.
Comment on the item you are talking about
Leave your comment on the specific deliverable rather than in a general message. That way the person doing the work sees your note next to the thing it refers to.
Say what you want, not only what is wrong
This feels too formal describes a problem. Can we make this sound more conversational gives the team something to do. The second version usually ends the discussion in one round.
Point to the specific part
Name the section, the paragraph, or the element. Feedback on a whole deliverable is hard to act on, and the team will usually have to ask which part you meant.
Separate must-change from preference
Say which points are essential and which are nice to have. Without that distinction, teams either treat everything as essential and overrun, or guess wrong and frustrate you.
Use approval for decisions, comments for discussion
Comments are for conversation. When you are ready to say yes or no, use the approval so the decision is recorded rather than buried in a thread.
What success looks like
- Your feedback is specific, attached to the right item, and clear about what matters most, so the next version addresses it without another clarifying exchange.
Common mistakes to avoid
- Leaving feedback by email, which separates it from the work.
- Describing a feeling without saying what you would prefer.
- Mixing essential changes and preferences in one list with no priority.
Common questions
Yes. Comments are visible to the team working on that project as soon as you post them.
Comment while you are discussing. Use Request changes when you are formally sending work back.
Related pages
Need something changed?
Ask your agency contact and they can adjust your access or share more projects.