Turn scattered design feedback into an actionable review

Design feedback often mixes observed problems with personal preferences and new scope requests. A useful review separates them so the designer knows what needs investigation and what has actually been decided.

Prepare the input

Supply the design goal, relevant screen descriptions or shareable images, feedback with source references, and approved constraints. Label comments from users separately from internal opinions. Do not assume an image alone proves an accessibility defect.

Run the workflow

Ask for feedback grouped by affected task and evidence. Keep conflicting comments visible. Distinguish a confirmed decision from a proposed direction and a question that needs testing.

Prompt to copy

Design goal and constraints: [details]. Feedback: [material].
Create a review table: user task, observation, source,
preference or evidence, proposed action, and open question.
Preserve contradictory feedback and identify the decision needed.
Do not invent user-test results or turn preferences into requirements.
Finish with the smallest useful validation step.

Review a worked example

Illustrative comments: “Make the button bigger” and “I could not find the booking action.” The second describes a reported task problem; the first is a proposed solution. The review should connect them without claiming that size is the proven cause. Check that approved constraints remain intact.

Check whether the proposed action addresses the reported task failure. Changing color may not solve an unclear label or a missing step. Keep alternatives visible until a decision or test resolves them. If feedback refers to different screen versions, separate those sources before drawing a conclusion about the current design.

Use it again

Have the design owner resolve decisions and record what was tested. Use new evidence to update the review. Explore Bot for individual preparation or contact Golub about a connected design workflow.