A design review produces a lot of feedback and almost no record of it. Half lands in scattered notes, half stays in someone's head, and afterward someone has to translate "we discussed some stuff" into actual issues, usually by hand, usually later.
In this tutorial you run a design review in Tana and leave with the work already tracked. Most feedback lands on issues that already exist, the issue for that screen, the spec, the PRD, updated in place with the new comment and the screenshot. Genuinely new changes get filed as new issues. Either way, the backlog is current before the call ends.
It works best with your tracker connected (Linear or GitHub), so the work lands where your team already lives. See Connect GitHub and Connect Linear. You need a design you can share on screen, a Figma file, a prototype, a build.
Run the review
Start a meeting in Tana, join, and share the design on your screen. Tana reads the screen you share and transcribes the conversation, so you do not narrate for the record or take notes.
Walk the design and react out loud: "the empty state needs a call to action," "this spacing feels off on mobile," "the error copy is too harsh." Move between screens freely. Tana follows both the conversation and what is on screen, so each comment stays connected to what you were looking at. It captures the shared screen, never anyone's camera.
As you go, or when you are done, have Tana pull the feedback together. It searches your existing issues and specs and, by default, updates the work each comment belongs to: a note added to the issue for that screen, a new acceptance criterion on the spec, the screenshot of what was on screen attached. Only genuinely new changes become new issues. You get updates to real work, not a pile of duplicates, and you do not have to set anything up for this to happen.
If a review is squarely about one tracked doc, you can pin that doc to the meeting as a strong hint, but it is optional. Tana looks for the matching work on its own.
Everything arrives as a proposal, so nothing changes until you say so. For each item you see whether it updates an existing issue or creates a new one, where it lands, and who it is assigned to, and for updates you see the before and after. Tidy the wording, drop anything that was just thinking out loud, reassign as needed, and accept.
By the end of the call, the work is where your team already looks. The designer and engineers open their tracker and the feedback is already on the right issues, assigned, with the visual context attached. Nothing to write up, nothing to re-file.
What you walked away with
The review used to end with a vague sense of "lots of feedback" and someone left to turn it into issues later. Now it ends with the tracker already updated: existing work enriched, new work filed, each item tied to exactly what was on screen.
The part a note-taker cannot do is the routing. Because Tana knows your issues and your spec, the feedback lands on the right things instead of becoming a fresh list you have to reconcile against work that already exists. That is the difference between a meeting that produced talk and a meeting that moved the work forward.