You are documenting how to refund an order, and the screen behind the refund button holds a left nav with fourteen items, a notification bell with a red 3, a chat widget in the corner, and a header with your own name and avatar. Capture the full frame and the reader has to hunt for the one control that matters. Three months later, even you will squint at it.
The captured still is the whole record. There is no drawing arrows or boxes on it later, only cropping the frame and dropping numbered pins. So the framing you do at capture time is the framing the reader gets. Here are four rules that hold up when the underlying app is loud.
Crop to the control plus one landmark, not the whole window
After you click Capture screen, drag the crop rectangle so it holds the thing the reader acts on and exactly one anchor that tells them where they are. For a refund, that is the order total row and the Refund button, plus the tab label above it. Drop the nav, the bell, the chat widget.
This works because a reader orients from one fixed landmark, not from the full chrome. Give them the tab name and the button and they know the spot. The failure mode when you skip it: you capture the whole 1440-pixel window, the button ends up 40 pixels wide in the corner, and the reader scrolls the image looking for what you meant. A tight crop is also the single biggest lever on whether the shot stays sharp, since you are not shrinking a huge frame down to fit. If yours comes out soft, the fix for a blurry captured screenshot usually starts with cropping tighter and capturing at full size.
Pin the exact spot, and let the number carry the order
When one crop holds two or three things the reader touches in sequence, drop numbered pins instead of writing "the button on the right, then the field below it." Pin 1 on the amount field, pin 2 on the Refund button, pin 3 on the confirmation checkbox. The reader's eye follows 1, 2, 3.
Numbers work because they encode order the prose does not have to. A comment that says "first check the amount, then click Refund" makes the reader map words back to pixels; a pin does the mapping for them. The failure mode without pins: the screen has two buttons that both say Submit, your comment says "click Submit," and the reader picks the wrong one. If you have several steps on one screen, numbered pins that force a reading order beat a paragraph every time.
Keep real data out of the frame or crop it off
A busy screen is usually a live screen, which means it is showing a real customer name, a real order number, an email address. On a doc anyone with the link can read, that data does not belong in the shot. Crop it out of the rectangle, or set up a test order before you capture so the values are safe to publish.
The reason is simple: the public URL of the form /r/<slug> is readable by anyone you send it to, and you cannot redact a still after the fact. The failure mode is worse than sloppy. You publish a how-to with a customer's address visible in the header and now you have leaked it to everyone on the review link. Decide before you click Capture whether the frame is clean.
Split noisy multi-step flows into one item per step
Do not stuff a whole procedure into one giant screenshot with eight pins. Each captured screenshot becomes its own item, so make each step its own capture with its own tight crop and its own comment. Step 1 is the orders list. Step 2 is the order detail. Step 3 is the refund dialog.
Separate items work because the reader consumes one screen, does the thing, scrolls to the next. One crowded shot with eight pins forces them to hold all eight in their head. The failure mode: you capture the final confirmation screen with pins pointing at controls that were on three earlier screens, and none of it matches what the reader is actually looking at. One item per step keeps the picture and the instruction aligned. This is the backbone of any quick documentation capture that reads cleanly later, and it is the same discipline behind a lightweight way to write one-off docs without heavier tooling.
Where dictation fits on a busy screen
When the crop is tight but the step has a caveat ("this button is greyed out until the payment settles"), talk it instead of typing. Cobalt Capture uses the browser's speech recognition in Chrome and Edge, so you narrate the caveat while the screen is fresh and move on. On Firefox the speech input is not available, so you type the note there.
The whole thing runs in a browser tab with no install, no extension, and no signup, so you can open a step, crop it, pin it, and publish without leaving the app you are documenting. When you are done, the review is a public link, and it exports to PDF, Word, or clean markdown a coding agent can read. Frame each capture tight at the source and the doc is already right the first time. Start a new capture on the screen you need to document and crop your first step.