How to review a design beyond “I like it” or “I don't”
Give feedback that connects an observation to the asset's objective and a specific test.
Key takeaways
- Review each proposal against the agreed objective.
- Separate content, hierarchy, and finish so you do not mix decision levels.
- Consolidate feedback and record what was approved.
A design review works better when it turns an observation into a decision. “I'm not convinced” expresses a reaction, but leaves the designer guessing the problem. You can keep that reaction as a starting point and turn it into feedback explaining what is happening, why it matters, and what should be checked.
Revisit the objective before opening the proposal
Start the meeting by recalling the audience, task, and context of use. Explain which stage of progress is being reviewed. A structural sketch does not need a detailed discussion of shadows if the main message is still undecided.
Also define the decision that should come out of the session: choosing a direction, correcting hierarchy, or approving a handoff. Without that expectation, a review can produce many opinions and no next step.
Review in layers of decisions
First check whether the information is correct and sufficient. Then observe reading order and the relationship between elements. Finally, review spacing, crops, and consistency. This order avoids polishing an asset that still communicates the wrong idea.
In a hypothetical example, a presentation announces a new service but opens with a long history of the studio. The main problem may be the narrative order. Changing the heading color does not solve the proposition arriving too late.
State the observation, consequence, and test
Useful feedback might say: “The button and heading have the same weight; I don't know where to look first; let's try a hierarchy where the message leads and the action is clearly separated.” Name what is observable and a consequence related to the task.
When you do not know the solution, describe the problem without inventing one. The designer can propose alternatives. If the disagreement depends on how the audience understands it, propose a comprehension test instead of settling it with a vote on preferences.
| Initial reaction | Useful observation | Next step |
|---|---|---|
| It looks crowded | Three elements compete to come first | Test a clear hierarchy |
| It does not look like our brand | Typography and framing differ from the guide | Compare with approved examples |
| Make it bigger | The name is unreadable at its usage size | Review scale or a compact version |
Group feedback and resolve contradictions
Designate someone to gather observations, remove duplicates, and identify conflicts. Do not send a list where one person asks for less information and another asks for more without explaining which need takes priority.
Classify each point as a blocker, improvement, or question. Connect it to an area or version of the asset. An annotated screenshot can help, but the feedback should remain understandable without another conversation.
Close with verifiable decisions
Write what stays, what changes, and what needs evidence. For each adjustment, name an owner and completion criterion. Avoid reopening approved aspects without a new reason; if the objective changed, update the brief before continuing.
In the next review, check the previous agreements first. This helps distinguish whether the problem persists or another has appeared. Review becomes a cumulative process rather than a new discussion from scratch.
Prepare a review with a clear decision
- Share the objective, version, and decision you need to make.
- Gather observations by content, hierarchy, and finish.
- Close with a short list of agreements and verification criteria.
Frequently asked questions
Who should participate?
The people needed to assess the objective, content, and execution. If there are many stakeholders, collect their observations beforehand and define who consolidates and who decides.
Is it wrong to say I dislike something?
No. Use it as a starting point and explain what you observe or expected. The reaction alone does not indicate how to improve the asset.
How do I choose between two proposals that work?
Compare maintenance effort, adaptability, and coherence with the system. If both meet the criteria, document the reason for the choice without inventing a claim that one is universally superior.
