You have twelve pieces of feedback on a new signup screen. Two are already fixed, three are questions, and the rest are real changes. You do not need a board with columns and assignees for this. You need to know which ones are done. A published review with per-comment resolution handles exactly that, and it does it without asking anyone to log into a tracker.
Here is the whole loop, start to finish, using nothing but a browser tab.
Step 1: Capture the screens that need feedback
Open a new review and click Capture screen. The browser asks which window or tab to share, and the current frame is drawn to a canvas. Drag a rectangle to crop down to the part that matters, for example just the password field and its error message, or use the full frame. That still becomes an item in the review.
Repeat for each screen. Say you capture the empty form, the filled form with a validation error, and the confirmation screen. Three items, three screenshots. If you want to point at something exact, drop a numbered pin on the spot so a comment reads "pin 2, the misaligned checkbox" instead of a paragraph of description. There is a short walkthrough on pinning the exact spot a reviewer means if you want the detail.
Step 2: Write the comment on each item
Type your note on each screenshot, or dictate it with the browser's built-in speech recognition in Chrome or Edge. "The error text overlaps the input border at 375px wide." "Confirmation button is fine, but the copy says 'Continue' twice." One comment per item keeps things findable later. You can also add a free-floating comment with no screenshot, useful for a general note like "whole flow needs the new brand font."
Keep each comment to a single, actionable point. If you tend to bury three requests in one paragraph, read the mistakes that make screen feedback hard to act on before you publish.
Step 3: Publish and get a shareable link
Click Publish. The review is saved and gets a short public URL of the form /r/<slug>. Anyone with that link can read every screenshot and comment, no signup, no install, no browser extension. Send it to the developer, the designer, or the client. You do not have to add them to anything first.
The same review is also available as a clean markdown export at /r/<slug>/markdown, plus PDF and Word. If a developer wants to paste the whole thing into a coding tool, the markdown is what they grab. Everyone else reads the link.
Step 4: Let people reply on the items they care about
Anyone with the link can post a comment on any individual item. So the developer can reply under the validation-error screenshot with "fixed in the next build, was a min-width rule." The designer can reply under the confirmation screen with "the double 'Continue' is intentional, second one is the fallback." The thread stays attached to the screenshot it belongs to, so nobody hunts for context.
This is where a lot of teams would open a bug tracker to catch the back-and-forth. You do not need one for a review this size. The replies live where the feedback lives.
Step 5: Mark each comment resolved as it gets handled
As the review owner, you mark each comment resolved once it is done. The validation-error fix ships, you mark it resolved. The font question gets answered, resolved. What is left is the true open list: the items still waiting on someone. No status columns, no dragging cards, no assignees to maintain. Just a running distinction between handled and not.
That single toggle is the tracking job most people reach for a heavier tool to do. It is also the core of why a lot of small teams treat Cobalt Capture as a lighter alternative to BugHerd: the review link is the ticket, the item is the bug, and resolved is the only workflow state you actually check. If your work genuinely needs a persistent board across many projects with assignees, that is a different tool. For a round of feedback on one build, resolving comments in place is enough.
When this covers the job and when it does not
This loop fits a design pass, a QA sweep on a staging site, or a client sign-off round. It closes when every comment is resolved and the link shows a clean slate. There is no ongoing board to tend after that.
It does not replace a bug tracker with cross-project reporting, sprint planning, or long-lived tickets that outlive a single review. If you are weighing the two side by side, the breakdown in BugHerd vs a no-login review link lays out which fits which situation. And if the receiver is a distributed team you are never online with, the same resolved-or-not view works across timezones with nobody on a call.
Start with one screen. Capture it, comment, publish, send the link, and mark the first reply resolved. That is the entire tracking system, and it took you a browser tab to build.