Support just answered the same question for the fourth time this week. You need an FAQ entry in the help center by end of day, with screenshots that match what users actually see in the product. You do not want to fire up a docs tool, mess with image uploads, or chase a designer for a Figma frame. Here is how to draft the entry in a browser tab and hand off something the help-center editor can paste straight in.
Decide what the FAQ entry has to answer
Before you capture anything, write the question the way a user would ask it. Not How do I configure two-factor authentication settings? but How do I turn on two-factor auth? Then write the shortest correct answer in one sentence. If you cannot do that, the FAQ entry is actually two questions and you should split it.
Now list the screens a user passes through to get the answer. For a turn-on-2FA entry that is usually four: account menu, security page, the QR code prompt, and the recovery codes screen. Four screens, four screenshots, four short comments. That is your outline.
Capture the screens in order
Open a new review in a browser tab. There is nothing to install and no signup to clear. Log into the product as a normal user would, in another tab, then walk the flow.
For each step, click Capture screen, share the product tab, and drag a rectangle around the part of the page that matters. For the account menu, crop tight to the dropdown. For the security page, crop to the 2FA row and its toggle, not the whole settings sidebar. The discipline that makes FAQ screenshots useful is cropping away everything that is not the answer.
If you need to point at a specific control, drop a numbered pin on the screenshot. A pin on the Enable button is worth more than a paragraph telling the reader where to look. Cobalt Capture does not let you draw arrows or boxes on the still, and you do not need them: a tight crop plus a pin does the job.
Write the comment that goes with each screenshot
Each screenshot becomes an item with a comment. Type or dictate. In Chrome and Edge the browser's built-in speech recognition is on; you can hold the mic button and narrate the step as if you were sitting next to the user. Firefox users type instead.
Keep each comment to one action and one outcome. Click your avatar in the top right, then choose Security. The 2FA row is third from the top. Not a paragraph about why 2FA matters. The FAQ entry is for someone who already decided to do the thing.
Add a free-floating comment with no screenshot for anything that is not a step: prerequisites at the top (You need access to the email on the account), and a troubleshooting note at the bottom (If the QR code will not scan, tap Enter key manually). Free comments without screenshots are first-class items in the review, so use them where prose is enough.
Publish and hand off in the format the help center wants
Click Publish. You get a public URL like /r/your-slug that anyone can open without logging in. That alone is often enough: paste the link into Slack for the support team, attach it to the ticket that triggered the FAQ request, and the question is functionally answered while the formal entry is being written.
From there, pick the format your help center actually consumes:
- If your help center accepts markdown (Notion, GitBook, Zendesk via import, most static-site help centers), open
/r/your-slug/markdownand copy the whole thing. The screenshots are embedded as image links. Paste into the new help-center article and adjust the question text. - If your help center uses a WYSIWYG editor that takes a Word doc, export the review as a Word document and import it.
- If a stakeholder wants to sign off before publication, send them the PDF.
The same source produces all three, so you never redo work when the help-center platform changes or someone insists on a different format. This is the workflow the FAQ authoring use case is built around: capture once, ship anywhere.
Let readers tell you the entry is wrong
Publish the public link inside the company even after the formal help-center article goes live. Anyone with the URL can post a comment on any item, and you mark it resolved when you have fixed the screenshot or the wording. When the product team renames Security to Account safety, the first person who notices comments on the screenshot, and you know exactly which step to recapture.
The owner-facing analytics page shows how many times the review has been visited and where from. If the support team is opening the link three times a day, the FAQ entry is doing real work and probably deserves promotion to a more prominent spot in the help center. If nobody is opening it, the question was not actually a frequent one.
What to do when the FAQ is about a bug, not a feature
Sometimes the frequent question is really users keep hitting this broken thing. The FAQ entry is a workaround, and the underlying issue needs a fix. Use the same review as the source for both: publish the help-center version, and use the same captures as the basis for a QA bug report to engineering. If the team uses an AI coding agent, the markdown export reads cleanly as agent-readable feedback and can go straight into the prompt.
For longer step-by-step content beyond a single FAQ answer, the same flow scales: see quick documentation for how to structure a multi-section walkthrough, or the writeup on one-off documentation when you need something between a tweet and a manual.
Open a tab, capture the four screens, ship the link before the next ticket lands.