How to run a remote design review
A design review is where a designer shows work in progress and the team helps decide what to change before it ships. On a remote team it often becomes a screen share where the designer clicks through frames, a few people react to whatever is on screen, and the feedback scatters across the call, comments in the design file, and DMs.
Run it from writing instead. Post the work with one clear question, collect feedback in a thread, then meet for a short block in an open voice room to decide.
The usual way
A remote design review often looks like this.
- The click-through. The designer walks through every screen while everyone watches, and the time for feedback runs out.
- The loudest opinion. Whoever speaks first sets the direction, and the quieter reviewers nod along.
- The scattered feedback. Some notes are said out loud, some land in the design file, some arrive in DMs a day later.
- The missing decision. The call ends with "great, lots to think about", and nobody knows which version won.
A format for a distributed team
1. Post the work with one question
The designer posts in the team channel a day ahead: a link to the work, two or three sentences of context, and the one question they need answered.
- What it is: New onboarding checklist, three screens
- The constraint: It has to fit on a phone without scrolling
- The question: Does the order of the steps make sense to someone on day one?
One question keeps the review on the decision that matters. Feedback on button colours can wait for the file comments.
2. Collect feedback in a thread, in writing
Reviewers reply in the thread before the meeting. Ask them to tie each note to a screen and to say what problem they see, not only what they would change.
- What works. The parts to keep, so they survive the next revision.
- What is unclear. Where a first-time user would stop or guess.
- What to try. A concrete alternative, with a reason.
Written feedback gives reviewers in other time zones the same say as whoever talks first on a call, and the designer gets every note in one place.
3. Keep the live review short
Meet for a short, fixed block. Talk in a walk-in voice room beside the channel instead of booking a call. The room is open, so whoever has context walks in, and someone who only needs the outcome reads the thread later.
The designer does not click through the whole thing. Everyone has seen it. The block has one job: go through the written notes where reviewers disagree, and settle them.
4. End with a decision, written down
Before the block ends, the designer posts the outcome as a reply in the thread.
- Decision: Move "Invite a teammate" to step one
- Why: Two of the three later steps depend on having a teammate in the channel
- Next: Revised screens in the thread by Thursday
If the review did not reach a decision, that goes in writing too, with who decides and by when.
5. Close the loop on the revision
When the revised work is ready, the designer posts it in the same thread. Reviewers see what changed against what they said, and the history of the design sits in one place.
Make it repeatable
- Pin the format. The next review starts from the last one's thread.
- Log the decisions. A design choice with a reason is a decision. Record it using the format in How to keep a decision log in team chat.
- One question per review. If the work raises three big questions, run three short reviews.
- Keep it in the channel. Feedback in DMs is feedback the rest of the team never sees. When DMs hide the decision covers why.
How Bullpen fits
Bullpen is team chat with walk-in voice rooms and AI helpers on the roster. A design review can live in one thread, from the first post of the work to the revised screens.
The feedback lives in the thread. Every note sits under the work it is about, in the channel the whole team reads.
The review happens in the channel's walk-in voice room. It stays open beside the channel. People walk in for the review and leave when it is done.
Wren writes the notes. Wren is an AI helper. In that walk-in voice room, Wren posts notes and action items back to the channel the room belongs to, so what was agreed out loud lands in writing.
Scout finds the earlier call. Scout is an AI helper on the same roster. Mention Scout and ask why the team chose the current onboarding order. Scout answers from what was said and links the message it came from.
Nix keeps the revision on schedule. When the designer commits to a date, mention Nix in the thread and the reminder arrives in the channel on the day. How to keep track of follow-ups in team chat covers the details.
Try it on your next review
Before booking a screen share, post the work in a thread with one question and ask for written feedback by the next day.