THE JENNA’S DAILY FIELD GUIDE
Design feedback that makes the next revision clear.
Turn vague reactions into specific revision requests with original examples, a copyable review note and a clear approval decision.
A designer receiving feedback needs to know which version you reviewed, what you noticed and which decision is required. A reaction such as 'this feels busy' can start a conversation, but it leaves the next step open. Use the examples below to turn a reaction into a reviewable request.
Start with the agreed job
Before commenting, read the brief's audience, message, destination and acceptance criteria. If the business objective changed, say so directly: a new requirement is different from a correction. Review one named version and nominate someone to resolve conflicting instructions. ProofHub's guidance similarly emphasizes objectives, observable issues and consolidated feedback. The examples and worksheet here are original editorial suggestions, not tested productivity claims.
Four reactions rewritten as useful notes
| Initial reaction | A more useful note |
|---|---|
| Make it pop. | On homepage-card-v02, I notice the background before the product name. The brief prioritizes the product. Please propose a version with a clearer product-name hierarchy; keep the approved copy. |
| This feels too crowded. | In event-card-v03 at its intended display size, the date and address are difficult for me to distinguish. Both are required. Please show a layout with more separation and check the result in the destination preview. |
| Use a different photo. | The current image shows a two-person service, but the approved offer is a single-person appointment. Please replace it with an image consistent with the service, and confirm permission to use it. |
| I liked the old version. | Version 01 gave the headline more space. Please retain that spacing while keeping version 03's corrected date. The updated date is required; the spacing is a preference for review. |
Copy this review note
- Asset and version: [exact filename or review link]
- Location: [headline, frame, section or timestamp]
- Observation: [what you can actually see or read]
- Reason: [the agreed requirement or audience need]
- Request: [the issue to resolve, with room for the designer's solution]
- Priority: [required correction / option to explore / personal preference]
- Approval owner and due time: [name, date and time zone]
Resolve disagreements before the next round
Suppose one reviewer asks to shorten a headline and another asks to add the full offer name. Forwarding both comments without a decision creates an avoidable conflict. The approval owner should check the brief, identify any mandatory wording and send one agreed direction. If the requirement is still undecided, mark that decision as pending instead of calling the file approved.
Close with an explicit status
| Status | What the recipient needs |
|---|---|
| Changes requested | One consolidated list of required changes and the next review time. |
| Decision pending | The unresolved question, its owner and when an answer is expected. |
| Approved for delivery | The exact version, destination and any agreed export requirements. |
Keep preference comments separate from required fixes so the designer can prioritize. Approval should refer to a specific version; a later copy change deserves another check. Once approved, use the creative handoff checklist to confirm the files, permissions and recipient access.
Missing the original brief? The creative brief tool can help record the agreed message and deliverables before another revision begins.
A few useful answers
Can I give feedback without knowing design terminology?
Yes. Point to the specific part of the asset, describe what you notice and explain the requirement it affects. You can ask the designer to propose a solution.
How many revision rounds should a project have?
Agree that with the people doing and approving the work. This guide does not assume a universal number. Record scope changes and confirm whether they need a new deadline or agreement.
Sources and further reading
MAKE THE NEXT HANDOFF EASIER