iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A useful review does more than say whether work is good or bad: it helps the work meet its goal without turning critique into a judgment of its author. A practical way to do that is to separate what you observe, what you want to ask, and what the team has decided—then connect any requested change to the outcome the work is meant to achieve.
Start with the goal, not your verdict
Before commenting on a design, document, or software change, state what it is supposed to accomplish. The relevant standard depends on the work: a screen might need to improve clarity or accessibility; a service flow might prioritize speed or reliable error recovery. Naming the goal gives reviewers and authors a shared basis for discussing choices instead of trading personal preferences.
Khanh Nguyen’s essay “A Better Way to Review” uses clarity, speed, accessibility, and reliable error recovery as examples of goals. The author’s central point is that useful feedback makes the work clearer without diminishing the person who made it.
Separate observations, questions, and decisions
These three kinds of comments do different jobs. Labeling them clearly helps prevent a question from sounding like a demand or an observation from being mistaken for a final decision.
#1 Best Overall
| Kind of feedback | What it does | Example |
|---|---|---|
| Observation | Describes something visible in the work, without assuming why it happened. | “The error message appears below the form after submission.” |
| Question | Invites context or tests an assumption when intent is unclear. | “What happens if this request fails?” |
| Decision | States what the team will do and, when relevant, whether that choice is final. | “Let’s keep the current placement for this release; we can revisit it after testing.” |
When you move from an observation to an interpretation, make the shift explicit. For example: “The action is only available at the end of the flow. I’m concerned that users may need it earlier. Could it be available on the previous screen?” The first sentence identifies what is present; the next explains the concern and opens a discussion.
Make a requested change specific and actionable
Criticism is useful when its recipient can tell what to examine, why it matters, and what kind of response is expected. Tie a suggestion to the stated goal rather than presenting taste as fact. “This feels clunky” gives little direction; “Could we reduce the steps before confirmation? The goal is to help someone complete the task quickly” gives the author a reason and a concrete area to investigate.
Rank #2
- Name the outcome: What should this work help someone do, understand, or avoid?
- Point to evidence: Identify the specific screen, behavior, passage, or code that prompted your comment.
- Explain the impact: Connect the evidence to the goal or describe the risk you see.
- Ask or request clearly: Use a question if context is missing; make a direct request if a change is needed.
- Clarify the status: Say whether the comment is optional input, a blocking issue, or a decision already made.
Respectful delivery does not mean avoiding difficult feedback. Directness helps when the issue is real; specificity and an open, professional tone make it possible to address the issue without making the discussion personal. Nguyen summarizes the principle this way: “Good reviews make the work clearer without making the author smaller.”
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Match the review to the work and its stage
A review should examine what is ready to be judged at that point—not hold an early idea to the standards of a finished deliverable. The criteria for an exploratory concept differ from those for final execution, and both differ from checks for consistency across a system.
Rank #3
Griff Designs describes this distinction in its icon-review workflow: early conceptual review considers viability; later executional review looks at stylistic detail; system refinement checks consistency and alignment. This is one design practice’s workflow, not a universal standard, but it illustrates why reviewers should say what kind of feedback they are giving.
- Exploration: Is the direction viable and aligned with the intended outcome?
- Execution: Are the details working for the agreed direction?
- System refinement: Does the item fit consistently with related elements?
For collaborative design work, Griff Designs also recommends having one client-side representative move designs through its review stages. A team may find a single person useful for consolidating comments and communicating decisions, but the appropriate owner depends on the project and its decision-making arrangements.
Rank #4
For code reviews, clarify intent and keep scope focused
Software changes need domain-specific scrutiny in addition to clear communication. GitLab’s code review guidance advises reviewers to understand why a change is needed and communicate how strongly they hold a concern. It also advises authors to explain why the code exists and keep merge requests small and focused.
In that setting, reviewers may examine requirements, edge cases, vulnerabilities, and maintainability. Those are software-review considerations, not a checklist to apply unchanged to a design critique or other creative work. Keeping a change focused also makes it easier to discuss one logical unit of work rather than mixing unrelated concerns.
Best Value
Make ownership and the discussion format clear
Several reviewers can offer valuable perspectives, but the author still needs to know who will reconcile conflicting comments and who has authority to decide. State whether feedback is open for discussion, whether a particular person is consolidating it, and who makes the final call. If a decision is not settled, say so rather than writing a preference as if it were already final.
Written comments work well when they identify the evidence and leave room for a response. If an exchange is not resolving an ambiguity or disagreement, a live conversation can help clarify the issue; record any resulting decision afterward so the team has a shared account of what was agreed. No single format or review workflow fits every kind of work.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
