You are ten screens into a review pass. You spot a broken empty state, a misaligned button, and a confusing label. Then you stop typing, tab back to the product, lose your place, and by the time your fingers catch up you have forgotten why the label bothered you. Typing is the reason a review that should take twenty minutes takes an hour, and it is why half your notes read as terse fragments a developer cannot act on.
Dictation fixes both problems. Cobalt Capture uses the browser's built-in speech recognition, so on each captured screenshot you press the mic, say what you see, and keep moving. What follows are the practices that make it work, and the failure mode each one prevents.
Talk in whole sentences, because the context is the point
When you type, you compress. You write button misaligned and move on. When you talk, you naturally say more: "The Save button sits about ten pixels below the Cancel button, and on mobile they stack in the wrong order so Cancel ends up on top." That second version tells the receiver what, where, and why it matters. The first version starts a back-and-forth.
This is the whole case for talking through a product review pass: you are trading a little verbosity for a lot of context, and context is exactly what gets a note fixed on the first try instead of the third. The failure mode when you type instead is a review full of two-word stubs. The developer reads them a week later, cannot reconstruct what you meant, and pings you to explain. You have now spent more total time than if you had said the full sentence out loud once.
Say the location, the observed behavior, and the expected behavior in one breath. That structure is what turns a comment into something a person or an agent can read and act on.
Capture the screen first, then talk about it
Each screenshot becomes an item, and dictation attaches to that item. Do the capture first. Crop to the part that matters if the full frame is noisy. Then narrate against the still image, which means you can describe what is right in front of you instead of from memory.
If you talk before capturing, or capture a different screen than the one you are describing, the comment floats loose from the evidence. The receiver opens the item, sees a screenshot of the dashboard, and reads a comment about the checkout form. Now they distrust every item in the review. Keep the pairing tight: one screen, one capture, then the words about that exact screen.
For spots that are hard to describe in words, drop a numbered pin and say "the field marked one" instead of "the third input from the top, or maybe the fourth." Pins and speech together are faster than either alone, and they remove the ambiguity that makes a reviewer and a developer argue about which element you meant.
Say the fix you would accept, not just the complaint
Dictation makes this easy because talking invites you to reason out loud. Instead of stopping at "this date format is confusing," you keep going: "It shows 03/04, which is ambiguous. Spell out the month so it reads March 4." You have now given the receiver a decision they can implement, not a problem they have to solve and then guess at.
The failure mode is a review that is all diagnosis and no prescription. The developer agrees the date is confusing, picks a format you did not want, ships it, and you reopen the same item next pass. When you dictate, add the acceptance criterion in the same sentence. It costs you five seconds and saves a round trip.
Check the environment before you rely on your voice
Dictation runs on the Web Speech API, which works in Chrome and Edge. In Firefox it does not, so you type there. If your review pass depends on talking, do it in a supported browser. The failure mode is discovering the mic does nothing halfway through a long session and having to retype everything from memory.
Two practical habits. First, review your dictated text before publishing; speech recognition mishears technical terms, and "nav bar" can come out as "navbar" or worse. Second, dictate in short passes rather than one long monologue per item, so a misfire costs you a sentence, not a paragraph. When you publish, the review gets a short public link, and the same content is available as a clean markdown export and as a PDF or Word doc, so whoever receives it, a client, a developer, or an agent, gets a format they can use.
When talking is the wrong tool
Dictation is not always faster. If your note is a single field name or a color hex value, type it; saying "hashtag F F three three A A" out loud is slower and more error-prone than typing #F33AA. Reach for the mic when the note needs context, a location plus a behavior plus a reason. Reach for the keyboard for precise strings and short factual corrections.
The point of a review is not to produce the most notes. It is to produce notes someone fixes without asking you a follow-up. Talking through each screen is the fastest path to that, and it costs nothing to try. Start a review, capture a screen, and say the first thing you notice out loud. You will feel the difference by the third item.