A design review that runs on email or scattered Slack messages produces the same predictable mess every time: three people commenting on three different versions of the same file, a designer trying to reconcile contradictory notes, and a round-trip that should have taken two days stretching into two weeks. A design review template fixes the format of the feedback. A design review process fixes the sequence it happens in. You need both, and most teams only have neither.
Here's the version we run, with a template you can copy straight into your next project.
Why most design review threads fall apart
The common failure isn't that people give bad feedback, it's that feedback arrives with no shared reference point. One reviewer comments on a screenshot from Monday, another opens the live staging link on Wednesday and comments on a version that's already changed twice, and a third replies to an email thread with "the header feels off" without saying which header, on which page, at which width. Nobody's wrong, but nothing is resolvable, because there's no single source of truth everyone is looking at when they leave a note.
The fix is structural: every round of review happens against one pinned version, comments are tied to a specific element rather than a general impression, and the round has a defined start and end instead of trailing off whenever people stop replying.

The reason to invest in this rather than wing it is a cost curve, not a preference for tidiness. The same defect gets dramatically more expensive to fix the later it's caught: 2026 defect-cost data puts the gap between fixing something at the design stage and fixing it in production at roughly 100x. A misaligned CTA caught in a structured design review is a five-minute comment; the same issue caught after launch is a hotfix, a re-deploy, and a client asking why it shipped. And the downstream stakes are real, roughly 68% of users abandon a site after two visible defects, so the review round is not busywork ahead of the "real" launch, it's the cheapest place on the timeline to catch the things that otherwise cost you a visitor.
The five stages
- Brief confirmation. Before any design work is shown, confirm the brief in writing, what problem this design solves, who's approving it, and what "done" looks like for this round. Skipping this is the single most common cause of a design review going sideways later, reviewers arguing about whether something is "wrong" when they actually disagree on the goal.
- First presentation. The designer walks reviewers through the work once, live if possible, so context and intent are established before anyone starts picking at details in isolation. A design shown cold, with no walkthrough, invites literal-minded nitpicks that a two-minute explanation would have preempted.
- Structured comment round. Reviewers leave feedback against the actual design, not a description of it, ideally pinned to specific elements at specific breakpoints. This is where most teams lose the most time, and where the process below actually earns its keep.
- Consolidation. One person, usually the design lead or account manager, reviews all comments, resolves contradictions before they go back to the designer, and flags anything that's actually a scope change rather than a design note. Sending a designer twelve raw, unfiltered, occasionally contradictory comments to sort out themselves is a process failure, not a feedback problem.
- Revision and sign-off. The designer addresses the consolidated list, and the round closes with an explicit approval, not silence. This step connects directly to a real client approval process, which covers the sign-off mechanics in more depth than this post does.
The template
Copy this into a doc or a project management tool at the start of every design review:
| Field | What goes here |
|---|---|
| Round | 1, 2, 3... never skip numbers, so everyone knows what "round 2 feedback" refers to |
| Version reviewed | Link to the exact file or live URL, timestamped |
| Reviewers | Named people, not "the team" or "marketing" |
| Deadline | A specific date and time comments are due |
| Comment format | Element + issue + suggested direction (not just "doesn't feel right") |
| Sign-off | Who has final approval authority for this round |
The "comment format" row is the one worth enforcing hardest. A comment that just says "this doesn't feel right" gives a designer nothing to act on except a guess. "The CTA button competes visually with the hero image, try increasing contrast or repositioning it" is a comment a designer can actually resolve on the first pass.
Running the live-site review specifically
Once a design moves from a static comp into an actual built page, the review changes shape, reviewers are now looking at something that renders differently by browser and breakpoint, not a flat image. This is where the "pin it to the exact element" discipline matters most, because a comment like "the spacing feels tight" means something completely different on a 1440px desktop than on a 375px phone, and a screenshot from one device doesn't communicate what's actually wrong on the other.
The fastest version of this we've found: reviewers comment directly on the live page at whatever width they're looking at, so the note carries its own context, no separate write-up needed. For the fuller comparison of tools and methods for this specific step, see website design feedback, which covers the live-review tooling landscape in more depth than this process post does.
If a round of feedback turns up a request for something more specific than a layout fix, a trending visual treatment, a frosted-glass card effect, a particular shadow depth, it helps to have something a designer or developer can dial in and hand off immediately rather than going back and forth in comments. Our free glassmorphism generator is a small example: adjust blur, tint, and border live, then copy the CSS straight into the build instead of describing the effect in words across three more review rounds.

How many rounds is normal
Most design work reasonably settles in two to three structured rounds: a first pass that surfaces the big-picture reactions (wrong direction, missing a key element, off-brand), a second pass that refines details once the direction is agreed, and an optional third pass for final polish. If a project is still generating substantial new feedback in round four or five, that's usually a sign the brief-confirmation stage was skipped or rushed, not that the designer is doing bad work. Going back to confirm the brief mid-project, awkward as that conversation can feel, is almost always faster than grinding through another open-ended round.
Where the process lives
None of the five stages above require a specific tool, they're a sequence, and you can run them in a shared doc, a project management board, or a dedicated review tool. What matters more than the tool is that every round has a documented version, named reviewers, and a deadline, written down before comments start arriving, not reconstructed afterward from a scattered thread. A lightweight template beats a heavyweight tool that nobody actually fills in consistently.
Common ways this process still breaks
- Too many reviewers on one round. More than three or four people commenting on the same design multiplies contradictions faster than it improves quality. Route wider input through the consolidator, not directly into the designer's queue.
- No deadline on the comment round. An open-ended review window means comments trickle in for a week, and the designer either starts revising on partial input or waits and stalls the whole project. Pick a deadline and hold it, even if that means a late comment waits for round two.
- Skipping consolidation on "simple" rounds. The rounds that feel simple enough to skip consolidation on are exactly the ones where two reviewers turn out to disagree, and the designer discovers that mid-revision instead of before starting.
- Treating "approved" as implicit. If nobody explicitly signs off, someone will eventually assume approval that was never given. Tie this process directly into a real approval step rather than letting a review round quietly become a launch.
Where Shotline fits
Shotline is built for the live-review stage of this process specifically: reviewers open a share link and pin comments directly to elements on the actual rendered page, at whatever width they're looking at, with no account or extension required. Comments carry the element, the viewport, and a screenshot automatically, so a note arrives with the context a designer needs instead of a paragraph reconstructing it. When a round is done, sign-off is a real recorded action, not an absence of new comments, which pairs directly with the client approval process this workflow feeds into.
Shotline is free to try for 14 days, no card required, then from $19/mo (billed annually; $25 month-to-month) with unlimited seats and unlimited reviewer guests. Start a free trial or see the whole workflow at the Shotline homepage.




