You just finished watching five usability sessions. Your notes are scattered across a doc, a spreadsheet, and a few screenshots you dropped into Slack. Now your PM wants the findings, and they want them in a form they can act on before the next sprint planning. Retelling each session in a meeting will not survive the week. You need one artifact that holds the evidence and the observation together.
Here is a concrete way to build that artifact from what you already have, using a browser tab and nothing else. No install, no extension, no signup to get started.
Step 1: Open a new review and pull up the first session replay
Go to start a new review in a browser tab. In a second window, open the session recording or the screen where a participant hit the problem you want to report. Scrub to the exact frame that shows it: the checkout form where three of five people stalled, the empty state nobody understood, the error message with no next step.
You are not recording video here. You are pulling a still that proves the point. If you have been wondering whether a frame beats a clip for written findings, the difference is covered in screen capture vs screen recording.
Step 2: Capture the frame and crop to what matters
Click Capture screen. The browser asks which window or screen to share, and the current frame draws to a canvas. Drag a rectangle around the part that carries the finding, the failed form field and its label, and drop the rest. Cropping is the only edit, and that is on purpose. A tight crop makes the PM look at the one thing you saw, not the whole page.
That captured, cropped still becomes an item in your review. Repeat for each session moment worth reporting. By the time you finish, you have a stack of items, each one a piece of evidence.
Step 3: Dictate the observation onto each screenshot
This is where synthesis happens. On each item, add a comment. In Chrome or Edge you can dictate with the browser's speech recognition instead of typing, which is faster when you are describing what a participant did and said. Speak the pattern, not just the incident: "Three of five participants tried to click the price to change quantity. Two gave up before finding the stepper."
Talking through findings tends to produce better observations than typing them, because you narrate the way you would in a debrief. If dictation is new to you, here is how to dictate your review comments. On Firefox, speech recognition is not supported, so you type instead.
Step 4: Pin the exact spot each observation refers to
When a screenshot has more than one thing going on, add numbered pins that point at the specific spots. Pin 1 on the price, pin 2 on the hidden stepper, and reference the numbers in your comment. Now the PM reads "pin 2" and knows precisely which pixel you mean. This is the same technique used for pointing at the exact spot a reviewer means.
Step 5: Add free-floating comments for cross-session patterns
Some findings do not live on a single screen. "Every participant expected the cart total to update live" is a pattern across the whole flow. Add it as a free-floating comment with no screenshot. Put these near the top so the reader gets the headline before the evidence. Mix screenshot items and text-only items freely; a good synthesis has both.
If your raw material is interview transcripts rather than session screens, the same assembly works, and there is a fuller walkthrough on turning raw interview notes into a shareable review.
Step 6: Publish and send the PM one link
Click Publish. The review saves and gets a short public URL of the form /r/<slug>. Anyone with the link can read it, no login required on their end. Paste that link into the PM's channel. They open it, scroll the findings top to bottom, and see the evidence attached to each observation.
The same review is available as a PDF and as a Word document if a stakeholder wants something to drop into a deck or a research repository. If an engineer or an agent is going to act on specific findings, the review is also at /r/<slug>/markdown as clean text. Building this kind of shareable artifact is the whole point of the user research synthesis workflow.
Step 7: Let the PM comment and resolve, in place
Anyone with the link can post a comment on any individual item. The PM can ask "how many sessions was this?" right on the finding, and you answer without a new email thread. As findings get scheduled or addressed, the review owner marks each comment resolved. It is not a bug tracker with assignees and columns; it is a lightweight way to resolve comments without a bug tracker, which is usually what a research handoff actually needs.
One more thing worth checking after you send it. Each review has an owner-facing analytics page showing visit counts and where visitors are located, so you can tell whether the PM and the wider team actually opened it. Reading those numbers is quick, and it tells you when to nudge. See reading the visit counts on a published review.
If you published before signing in, the review is kept for 30 days as an anonymous one; sign in with Google or a magic link to claim it permanently. Start your synthesis on the next session you watch, and you will have a sendable link before the notes go cold.