You write an FAQ entry once, and it has to answer the same question for months. The person reading it next week is not you, and they do not have the context you had while the screen was in front of you. That is the test: not whether the entry made sense while you captured it, but whether it still points somewhere concrete when a stranger opens it cold.
Two capture mistakes fail that test almost every time. Both are easy to make because they feel fine in the moment. Both are cheap to fix if you catch them before you publish.
Mistake 1: A screenshot that shows the whole screen when the answer lives in one corner
The question is "How do I change my billing email?" You capture the full account settings page and paste it in. The screenshot is technically correct. It contains the billing email field. It also contains the sidebar, the plan summary, three other tabs, a notifications toggle, and a banner about an unrelated feature.
This is tempting because capturing the whole screen is the default. You share the window, the frame gets drawn, and the easy move is to leave it as is. Cropping feels like extra work for an entry that already looks done.
The cost shows up on the second read. Someone scanning your FAQ for the billing email answer gets a wall of interface and has to hunt for the one field you meant. If the page layout shifts even slightly in a redesign, your uncropped shot ages badly because it is documenting the whole page rather than the one control that matters.
The fix is to crop the captured still down to the region that answers the question. In Cobalt Capture, cropping the frame is the one image edit available, and that constraint works in your favor: you drag a rectangle around the billing email field and the Save button next to it, and everything else drops away. The reader sees the field, the label, and the action, and nothing to sort through. Cropping tightly is the single habit that separates a reusable entry from a screenshot dump, which is why it sits at the center of any workflow for writing FAQ entries that people actually reread.
If you are unsure how tight to go, keep enough surrounding context that the reader knows where they are, and cut everything that does not help them act. A cropped field with its label beats a full page every time. There is more on the reasoning behind that in the case for a cropped still over an annotated live page.
Mistake 2: Steps that reference the screenshot but the screenshot has no numbers
The second failure is subtler. Your entry has a clear cropped shot and a clear set of steps. The steps say things like "click the dropdown, then select the option below it, then confirm." The screenshot shows all three controls. Nothing connects step two of the text to the actual dropdown in the image.
This is tempting because you know which control is which while you write. The dropdown is obvious to you. So the words "the dropdown" feel specific enough. They are not, for a reader who is seeing the screen for the first time and counting three things that could plausibly be a dropdown.
The reader ends up doing the translation you skipped. They read "select the option below it," look at the image, and guess which element you meant. On a busy screen that guess is wrong often enough to generate the support ticket the FAQ entry was supposed to prevent.
The fix is numbered pins. Drop a pin on each control the steps refer to, in the order the reader will touch them, then write the steps to match: step 1 points at pin 1, step 2 at pin 2. Now "click the dropdown" becomes "click 1," and there is no interpretation left to do. This is the difference numbered pins make when someone reads steps in order, and it applies just as much to a customer following an FAQ as to a developer following a bug report.
Pins also survive dictation well. If you talk through the entry rather than type it, you can say "pin one is where you click first, pin two is the field you fill in," and the numbers keep your spoken walkthrough tied to the image. More on pinning the exact spot a reviewer means if you want the full pattern.
How to catch both before you publish
Read your entry the way the next person will. Open it as if you have never seen the screen, and ask two questions. Can you find the thing the answer is about without scanning? If not, crop harder. Does every step tell you exactly where to look on the image? If not, add pins and rewrite the steps to name them by number.
Both checks take under a minute per entry, and both happen before you hit Publish, while the frame is still in front of you and fixing it is trivial. After you publish, the entry gets a short public link anyone can open with no login, and the same content is available as a clean export you can drop into your help center. It is free, runs in a browser tab, and needs no install, so there is nothing stopping you from redoing a weak entry the moment you notice it.
The best time to fix a vague screenshot or a numberless pin is now, before a reader turns it into a support ticket. Start a review and capture your next FAQ entry with the crop tight and the pins in order.