Design reviews that end in issues, not opinions
Why most design reviews produce a pile of comments and no work - and a practical structure for running one that ends with tracked issues, a named decision, and a record you can read six months later.
Aug 25, 2026 · 4 min read · Kash Gohil
You know the review. Eleven people in a call, a board on screen, forty minutes of reactions. Everyone leaves having said something. Nothing is assigned. Three weeks later the same objection is raised by the same person, and nobody can find the thread where it was answered the first time.
The problem is not that people give bad feedback. It is that the review has no output. This post is a structure that produces one.
Why reviews produce nothing
Three failures, and they compound.
The artefact and the argument live apart. The design is in one tool, the discussion in another, the work in a third. A comment cannot become an issue without a human retyping it, so most comments never become anything.
Nobody is on the hook for a decision. "Let's think about it" is a valid ending when no one owns the close. The review becomes a place to raise concerns rather than a place to resolve them.
The record is a transcript, not a conclusion. Six months later you can find what people said and not what was decided, which means the decision gets made again - usually differently.
The structure
1. The design arrives with a question, not a reveal
A review with no question is a demo. Before it starts, the author writes what is actually being asked: Is this the right structure for the settings page, or should the destructive actions be a separate screen?
That single sentence changes who talks. A reveal invites reaction from everyone; a question invites an answer from the people who have one.
2. Comments go on the thing, not in a channel
Feedback belongs anchored to the element it is about - the frame, the paragraph, the node. This is not a UI preference. A comment on a channel is about a memory of the design; a comment on a frame is about the design, and it survives the frame moving.
The practical difference shows up at read time. "The empty state is wrong" in a channel is unanswerable in a month. Anchored to the empty state, it still points at what it means.
3. Someone signs off, and it is not the author
Make the close a real event with a rule attached: the move to approved needs a sign-off from somebody other than the author, and it is refused while a request for changes still stands.
Two things follow. The review has a definite end, which is what stops it being reopened at random. And the sign-off is a fact you can look up rather than a feeling about whether everyone seemed happy.
Nothing here is exotic; it is code review's own rule, applied to a design. Design work is the last place in most teams where a change ships with nobody's name on the approval.
4. The output is issues, filed from the review
This is the step that makes the whole thing worth doing. Every concern that survived the discussion becomes a tracked issue, filed from the document, keeping the link back to the section it came from.
Concretely, an hour's review ends with:
- a decision, and who signed it
- three issues in the backlog, each pointing at the paragraph that motivated it
- the objections that did not become work, answered in the thread, so they are answered for good
The failure this replaces is the review whose output is a Slack summary that decays in a week.
5. Read it back before the work starts
Before anyone builds, the person doing the work reads the design and the thread together. If they cannot tell what was decided, the review failed and it is cheaper to find that out now than in a pull request.
Where agents fit
If agents work in your codebase, they are also review participants, and the same rules apply to them without modification. An agent reviews through the same endpoint a person does and is held to the same author rule - it cannot sign off on the draft it wrote.
The useful pattern is not "the agent approves things". It is the agent doing what a diligent reviewer does and rarely has time for: reading the spec against the code, and filing the issue for the case the spec did not cover, with the section it came from attached.
What to drop
Some habits cost more than they return.
- Round-the-room feedback. It produces comments from people with nothing to say, which is noise the author has to sort.
- The design review meeting as a recurring calendar slot. Review a design when there is a design and a question. A weekly slot fills itself with whatever is nearest.
- "Any objections?" as a close. Silence is not agreement, it is silence. A sign-off from a named person is agreement.
The test
You do not need a maturity model to check if this is working. Six months after a decision, ask what was decided and why.
If the answer is a document with the objections and the sign-off still on it, and issues that point back at it, the review worked. If the answer is somebody's memory, it did not - and you are about to have the same conversation twice.