In short
A design review runs in four stages: preparation, review, consolidation and sign-off. Each stage has its own owner and its own timebox so feedback doesn't run indefinitely.
Why design reviews often drag on
Without a fixed structure, a design review turns into an open-ended discussion where anyone can add new points at any time. A staged structure limits when which feedback is admissible.
Stage 1: Preparation
The designer or team provides the version to be reviewed – on a staging page, not a static image, so reviewers see real behaviour. Owner: design lead.
Stage 2: Review
All reviewers look at the version independently and leave notes directly on the element. This stage runs asynchronously and needs no shared meeting. Owner: each reviewer individually.
Stage 3: Consolidation
One responsible person reviews all notes, removes duplicates, resolves conflicts and prioritises. This stage needs clear decision authority, or conflicts remain unresolved. Owner: project lead or design lead.
Stage 4: Sign-off
After the prioritised items are implemented, a named person confirms approval in writing. Owner: client or product owner.
A realistic timeline
For a mid-size project, this timeframe has proven workable:
- Preparation: 1 day
- Review: 2–3 days, in parallel for all reviewers
- Consolidation: 1 day
- Implementing prioritised items: 2–5 days depending on scope
- Sign-off: 1 day
Who should take part in a design review?
Reviewer roles differ in perspective, not just hierarchy:
- Design lead: consistency with the design system
- Development: technical feasibility
- Business/client stakeholder: content accuracy
- Accessibility check: contrast, readability, keyboard use
Synchronous or asynchronous?
A shared meeting works for fundamental decisions but is inefficient for detail feedback. Asynchronous notes directly on the element allow parallel work without scheduling.
Design feedback vs. matters of taste
A review should separate violations of the design system (objective) from personal preference (subjective). Only the former should automatically trigger a change.
Running design reviews remotely across time zones
With distributed teams, the focus shifts almost entirely to the asynchronous review stage, since a shared meeting rarely works across every time zone. Notes directly on the element replace the meeting: each reviewer leaves a comment, screenshot context and priority without waiting for a real-time reply. What matters is a clearly communicated deadline in a neutral time zone (e.g. UTC) and a short daily update from the person consolidating, so reviewers elsewhere can see progress without having to ask. An optional, short synchronous call at the end of the review stage only needs to resolve points that couldn't be settled in writing.
How do you measure whether a design review worked?
A design review succeeded if three things hold true: sign-off happens within the planned timeframe, no fundamental change requests appear after approval, and the number of open points visibly drops with each iteration instead of growing. A simple indicator is the time from the first note to final sign-off – if that period shrinks across projects, the process is working. If instead the number of iterations climbs, or round three still surfaces points that should have come up in round one, that points to unclear role assignment or key reviewers being brought in too late.
Common mistakes in the review process
These patterns needlessly extend a design review:
- Feedback arrives through several channels at once
- No one is named responsible for consolidation
- Reviewers get no update on the status of their own points
- The final stage (sign-off) is never explicitly requested
Checklist for a structured review
Before starting a review:
- A staging link with the current version is ready
- The reviewer list has clear roles assigned
- A deadline for the review stage has been communicated
- A person responsible for consolidation is named
Frequently asked questions
How many reviewers is sensible?
Three to five with clearly different perspectives; more reviewers usually generate more conflict than insight.
Should a design review happen before or after development?
Ideally both: once on the mockup, once on the built version, since details only show up live.
How do you handle conflicting feedback from two reviewers?
The person consolidating decides based on the design system, or escalates to the product owner.
What if the consolidation stage takes too long?
Usually there's no clearly named person with decision authority – that's the most common cause.
Does every project need four stages?
Small projects can merge preparation and review, but should still keep consolidation and sign-off separate.
How do you document a review's approval?
In writing, with date, reviewed version and the approver's name.
How do you structure feedback that came out of a meeting?
Turn every point raised in the meeting into a note on the affected element immediately, instead of reconstructing it from minutes.