“A useful revision request describes an observable problem, consequence, constraint, and decision needed. It gives the designer room to solve the issue while removing ambiguity about what must change.
Diagnose the failure
“Make it better” mixes taste with diagnosis. The designer cannot tell whether the issue is hierarchy, legibility, missing proof, wrong audience, inaccurate property detail, or approval politics. Vague feedback produces defensive iteration and another round of guessing. A revision request should describe the observed problem before prescribing a solution.
Use a decision framework
Write four lines: observed issue, user or business consequence, non-negotiable constraint, and requested check. Prefer “buyers miss the viewing action below the image” to “the CTA feels weak.” If evidence is a hypothesis, label it and suggest an observation that could confirm it. Give the designer room to solve.
A hypothetical real estate example
Implement and measure
Use annotated screenshots, one numbered request per issue, and a priority field. Confirm interpretation before production and close each item against the original observation. Measure rework rounds, clarification time, reopened issues, and task success in a small comprehension test when relevant. Good feedback reduces search space without dictating the solution; that is the designer’s productive freedom. The request should help the designer decide what to change and why the change matters.
Put it to work
- Describe the observed problem, not your taste.
- State constraints and the decision to test.
- Close each change against its original issue.
Sources and visual credits
Illustrative photograph: Person writing in notebook while using laptop at a modern workspace. It does not depict the hypothetical example. Shixart1985 · CC BY 2.0 · Wikimedia Commons · CC BY 2.0