Short answer: Dictate the narrative parts of a bug report (steps, expected versus actual, context) and type the exact values (versions, IDs, error strings, URLs). Click into the issue body first, hold your dictation hotkey, describe the failure out loud, then edit. Speaking runs 130-150 words per minute against roughly 40 typed.
Open any issue tracker that has been running for more than a year and read the oldest open tickets. A pattern shows up almost immediately: the titles are specific and the bodies are thin. "Export is broken." "Doesn't work on mobile." "Same as before but worse." Three months later nobody can reproduce them, and they get closed as stale rather than fixed.
The usual explanation is discipline. People are sloppy, or they are in a hurry, or they never read the contributing guide. That explanation does not survive contact with the actual moment the report gets written. You are in the middle of something else when you hit the bug. You noticed the failure in about two seconds. Writing down what you noticed, in enough detail that a stranger can reproduce it, takes forty seconds to two minutes of typing. The gap between those two numbers is where bug reports go to die.
That is an input cost, not a character flaw. And it is the one part of the problem that can be changed without changing anybody's habits, because most people can already speak a complete reproduction sequence in the time it takes to type the first line of one. The adult average typing speed sits around 40 words per minute. Conversational speech runs 130 to 150. A five-sentence repro that costs you ninety seconds of typing costs about twenty seconds of talking.
What a fixable bug report actually contains
Before the mechanics, it is worth being precise about what you are trying to produce, because "write more" is bad advice. A long report full of speculation is worse than a short one with the right facts. A report that someone can act on has five parts, and only three of them are prose.
- A title that describes the failure, not the area. "Export" is an area. "CSV export produces an empty file when the filter returns zero rows" is a failure.
- Environment and version. Build number, OS, browser, device, account type. These are values. Type them or paste them.
- Steps to reproduce. Numbered, starting from a known state, with no steps omitted because they seemed obvious. This is prose, and it is the part that gets truncated.
- Expected versus actual. Two sentences. This is prose, and it is the part people skip entirely because they assume the failure is self-evident.
- Context the reader cannot get from the app. How often it happens, whether it started recently, what you were actually trying to do, what you already ruled out. This is prose, and it is the part that most often decides whether the bug gets prioritised.
Three of the five parts are sentences. Sentences are exactly what voice is good at, and exactly what a keyboard makes expensive when your hands are already busy driving the app that just broke.
The rule: speak the sentences, type the values
This is the single most important habit, and it is not a limitation of any particular tool. It comes from how errors fail.
Prose defends itself. If a dictated sentence comes out garbled, you can see that it is garbled. "The dialogue closes before the safe completes" reads as wrong the moment your eyes cross it, and you fix it.
Data does not defend itself. If you speak a build number and it lands as 4.7.13 instead of 4.7.3, the report looks perfectly correct. An engineer checks out the wrong build, cannot reproduce the failure, and closes the ticket as not-a-bug. A wrong digit in a customer ID, a transposed character in an error code, a URL with a missing path segment: all of these read as correct forever, and every one of them costs someone an afternoon.
So the division is:
- Speak: the steps, the expected behaviour, the actual behaviour, the impact, the frequency, what you already tried, what you suspect and why.
- Type or paste: version and build numbers, timestamps, request and trace IDs, account or order identifiers, URLs, file paths, error codes, stack traces, config values, and anything you would copy out of a console.
In practice this feels like: you speak the whole report in one pass, leaving a spoken placeholder like "build number here", and then you go back and paste the values in. The two-pass approach is faster than switching modes six times, and it keeps you from losing the thread of the reproduction while you hunt for a version string.
Dictating while you are still in the failure
The best bug report is written while the broken state is still on screen. Once you have closed the tab and moved on, you are reconstructing from memory, and reconstruction is where "and then something happened" comes from.
A workflow that survives real conditions:
1. Do not leave the broken state
Before you refresh, retry, or close anything, capture. Screenshot first, because a refresh can destroy the evidence. Then open the issue tracker in a second window rather than navigating away in the one that is broken.
2. Narrate the steps backwards from where you are
The hardest part of a repro is remembering how you got there. Say it out loud while looking at the broken screen: "I'm on the invoice detail page. I got here from the invoice list. Before that I filtered by last quarter. Before that I logged in as a read-only user." Then reverse it when you edit. Speaking backwards from the current state is far more reliable than trying to recall forwards, and it costs nothing to try because the words are cheap.
3. Say expected and actual as two explicit sentences
Force yourself to speak both, even when the failure seems obvious. "I expected the total row to show the sum of the visible rows. It showed the sum of all rows including the ones the filter removed." That sentence pair is often the entire diagnosis, and it is almost never written when typing is the input method, because by the time you have typed the steps you feel finished.
4. Add the context nobody asks for
Say how many times you have seen it, when it started, whether a colleague can reproduce it, and what you already eliminated. Twenty seconds of speech here saves a round trip that would otherwise take a day.
5. Edit before you submit
Read it once. Fix the identifiers. Cut the sentence where you changed your mind halfway through. Dictated first drafts have a specific texture: false starts, a doubling back, an "actually" in the middle — and cleaning that up takes far less time than composing it did. Our guide to editing dictated text covers the two-pass method in more detail.
Where dictation fits in a tracker, surface by surface
The issue body
The obvious one, and the highest value. This is where the five parts live. Click into the body field first, then dictate. A common first-run mistake is holding the hotkey while the page has focus but no text caret, which produces nothing at all.
Comment threads and triage replies
Comments are where a bug either gets resolved or gets stuck, and they are usually the worst-written text in the tracker. "Can't repro" is a comment that costs the reporter another cycle. "Can't repro on build 4.7.3 on an M-series Mac with a fresh account. Reporter is on a seat with the legacy permission set, so it may be permission-scoped" is a comment that ends the ticket. The difference is thirty seconds of speech. If your team works in issues and pull requests, our post on dictating in GitHub covers the same surfaces from the code-review side.
Exploratory testing session notes
If you test for a living, the running log of a session is the artefact that decays fastest under typing pressure. You cannot type a note without stopping the exploration, so the notes get compressed to keywords that mean nothing a week later. Speaking them keeps your hands on the application and your attention on what it is doing. Voice typing for QA engineers goes deeper into the testing-session workflow.
The bug you cannot reproduce
Intermittent failures deserve a longer report, not a shorter one, because the only thing you have is context. Everything you noticed (time of day, network condition, what else was running, how long the session had been open, whether it followed a specific action) is a candidate signal. This is the report that never gets written properly by hand, because there is nothing satisfying to type. Speaking a paragraph of "here is everything that was true when it happened" takes under a minute.
Customer-reported bugs
Support and success people are the highest-volume bug reporters in most companies and the least likely to have a keyboard-heavy workflow. The translation step from "customer said the thing is broken" into a report an engineer can work from is pure prose, plus a handful of IDs. It is the ideal shape for dictate-the-sentences, paste-the-values.
The traps: focus, hotkeys, and the Enter key
Issue trackers are keyboard-driven applications, and that creates three predictable first-run failures.
Single-key shortcuts. Many trackers bind bare letters to actions when no field has focus. If your dictation hotkey overlaps a modifier combination the tracker claims, you will trigger a command instead of recording. The reliable fix is to use a function key (F13 through F19 are effectively unclaimed on macOS) or a lone right-side modifier. Set it once and it works everywhere, including the editors and terminals where collisions are worse.
Selection is not insertion. Clicking a card, highlighting a comment, or having the page focused is not the same as having a text caret in a field. Click directly into the text area, see the cursor blink, then dictate.
Return submits. In a lot of comment boxes and quick-add fields, a newline sends the message. If you dictate a report with spoken paragraph breaks into one of those, you will post four fragments instead of one report. Compose long reports in the full editor, not the inline quick-add, and treat any single-line field as one dictation with no line breaks.
There is also a markdown-specific annoyance worth knowing: if the editor auto-continues lists, a dictated numbered sequence can end up double-numbered. Dictate the steps as plain sentences and add the list formatting afterwards with the keyboard. Formatting is the keyboard's job; the words are yours.
Your product's vocabulary is the accuracy problem
Every team has thirty or so words that no general transcription system has ever seen: internal service names, the codename of the deprecated billing flow, a component library, the surname of the engineer who owns the queue, an acronym you invented in a meeting two years ago. These are exactly the words that appear in bug reports, and having to correct the same six of them every time is the single most common reason people try dictation for a week and quit.
The fix is a personal dictionary. Voice Keyboard Pro's Smart Vocabulary lets you add terms and replacement rules so that your service names, product areas, and internal acronyms come out right without a second pass. The practical advice is to build it from real corrections rather than in advance: dictate for two days, note what you fixed by hand more than once, and add those. Twenty to thirty entries usually covers an entire team's jargon. Our post on teaching dictation your custom vocabulary covers how to structure the list.
One caveat specific to engineering work: do not try to make the dictionary handle identifiers with mixed case and underscores. Type those. A vocabulary list is for words you say out loud in conversation, not for symbols you would only ever read.
Bugs you find on your phone
A large share of bugs are noticed on a phone, away from a desk, and that is exactly where a good report is least likely to happen. Typing a five-step repro on a phone keyboard is unpleasant enough that most people send themselves a two-word reminder instead, and the two-word reminder is useless by evening.
Voice Keyboard Pro's iPhone keyboard has a mic button built into the keyboard itself, so it works inside whatever app you are already in: the tracker's mobile app, a browser tab, a Slack thread, a note. You can speak the whole report at the moment you hit it, while the state is still on screen. Voice Edit lets you speak a correction to fix a line rather than tapping through it with a cursor, which is the part of mobile writing that actually costs the time.
The useful habit: capture the full narrative on the phone, and add the identifiers and screenshots later at a desk. A wordy mobile report with a missing build number is far more valuable than a terse one, because the words are the part that cannot be reconstructed.
A template you can speak
Templates help most when they match the order you would naturally say things. This one is designed to be spoken top to bottom in about a minute, leaving the values for a second pass.
What broke, in one sentence. What I was trying to do. The steps, starting from logged out. What I expected. What actually happened. How many times I have seen it and when it started. What I already ruled out. Environment and IDs to fill in.
Note the ordering. Most written templates start with environment, which is the part you have to go look up, so the report stalls before it begins. Speaking starts with what you know and ends with what you have to fetch, which is why it finishes.
Honest limits
A few things dictation does not do, stated plainly so you can plan around them.
- It does not write code, and you should not dictate code. Punctuation density and identifier casing make spoken code slower and less reliable than typed code. Speak comments, commit bodies, and reasoning. Type the syntax.
- It does not triage. A longer report is not automatically a better one. The five-part structure is still your job.
- It needs a connection. Transcription runs in the cloud, so an air-gapped test lab is out of scope.
- It is audible. Reading a customer's account details out loud in an open-plan room is a disclosure, regardless of what the software does. Never speak credentials, tokens, or personal customer data. Type those, or better, do not put them in a ticket at all.
On privacy: Voice Keyboard Pro's servers store only operational pings. No audio and no transcript content is retained. That matters for anyone reporting bugs against systems under an NDA, though the honest framing is that the person sitting two metres away is a bigger consideration than the network. Read our policy yourself rather than taking a marketing line as a control.
Frequently asked questions
Does this work with Jira, Linear, GitHub, and the rest?
Yes, because it types at the cursor rather than integrating with any one tracker. On Mac you hold a hotkey and text appears wherever your caret is: a web tracker in any browser, a native app, a terminal, a chat window. Nothing is installed into the tracker itself, which also means nothing breaks when it updates and nothing needs approval on a locked-down work machine.
Will it get the punctuation right?
Ordinary sentence punctuation comes out correctly in normal speech. What you should not expect is for it to guess structure. Numbered lists, code blocks, and headings are formatting decisions, and formatting is faster with the keyboard.
Should I dictate the stack trace?
No. Copy and paste it. That is the clearest case of the speak-the-sentences, type-the-values rule.
What about reports in another language?
If your team writes tickets in a language you are not fluent in, two-way translation while dictating covers 24 languages, so you can speak in the language you think in and produce the ticket in the team's language. Treat the output as a solid first draft and read it before you post, particularly for anything customer-facing.
Is there a free version?
Yes. Voice Keyboard Pro has a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. For a bug-report habit specifically, the free tier is enough to find out within a week whether your tickets get longer.
The test
Do not take any of this on argument. For one week, dictate every bug you file and keep doing everything else the way you do it now. At the end of the week, open your tracker and compare that week's reports against the month before. You are not looking for elegance. You are looking for whether the steps are complete, whether expected-versus-actual is present, and whether anyone had to come back and ask you a question before starting work.
The reason this usually shows a difference is not that voice makes people more thorough. It is that thoroughness was never the constraint. The constraint was that the report cost more to write than the bug cost to notice, and that the person best placed to describe the failure was the person least willing to spend two minutes typing. Voice Keyboard Pro removes the cost. The reports that follow are just the ones you would have written all along if writing had been free.