Describe the problem before the instruction
“Make this bigger” and “change the colour” prescribe an action without necessarily identifying a problem. Explain what readers misunderstand, cannot find or experience as inconsistent with the agreed direction. For factual corrections, provide the correct information and its basis. The client does not need design terminology, but the designer needs to understand what improvement the change should achieve.
A request for a larger heading may mean poor mobile legibility or weak hierarchy. One needs a size check; the other may need different information relationships. Describe the observation: “On mobile, the explanation overwhelms the product name; the product should be recognised first.” Stating the conditions and desired change opens the discussion to suitable solutions rather than an untested action.
Review the right level at each stage
At structure stage, review order and missing content. At representative-page stage, assess hierarchy and visual direction. During rollout, check consistency and individual details. Reopening the audience at final review affects the whole set and requires a scope and schedule discussion. Stage-based review also avoids spending early meetings on pixels before the message is settled.
State the main decision for each review and list deferred topics separately: content and reading order first, colour details later, for example. Raise factual errors as soon as they appear. Staging gives discussion focus rather than excluding legitimate issues. If the work must return to an earlier decision, identify the previously approved outputs affected.
Resolve conflicting instructions
A day-to-day contact should consolidate comments while the final approver resolves important trade-offs. Preserve the reasoning behind disagreement, but do not send mutually incompatible instructions to production. Identify the page, location and version for each item. Add decisions reached verbally to the same list so the next round does not revive superseded comments.
Keep the source and reason for each comment, then give a coherent decision. If sales needs more explanation while management wants a simpler page, consider a later page, caption or supporting document. Mark unresolved conflicts for the approver instead of sending simultaneous add-and-remove instructions. The implementer needs the decision, not a puzzle assembled from chat chronology.
Check the consequences of a fix
Verify the requested correction and its effects nearby. A longer heading can change card height; a new image may crop differently on a phone; revised product information can require an English update. Record what this round approves and leave unresolved items visible. Coordinated feedback gives each comment an object, outcome and status rather than simply reducing the number of comments.
Follow references: a renamed product may affect contents, headings and translation; a new image may affect covers, detail views and sharing previews. Punctuation does not reopen the visual system. Match review to the changed object, then check shared templates. This catches consequences without turning a small correction into an unlimited redesign.
Define when a comment is resolved
Use a check suited to the issue: compare corrected copy with its source, review discoverability at real size, or compare inconsistent pages side by side. Keep unresolved disagreements open; silence is not approval. Clear closure criteria let both sides finish a review and distinguish new issues from incomplete earlier changes.
Use a closing condition the person raising the issue can assess. “The three desktop links share a baseline and mobile text is not clipped” is clearer than “improve the layout.” Review the relevant page or actual-size capture, keeping failures with the same issue. For a comment such as “make it feel better,” establish a reference and reason before another production round.
