← Back to Blog

Short answer: Dictation for technical writing works best when you draft prose by voice and reserve the keyboard for code and precise formatting. Speak full sentences, say punctuation aloud, and store product names and acronyms in a custom dictionary so the transcription engine spells them correctly every time.

Technical writing is one of the most keyboard-intensive jobs there is. A single product release can mean a fresh user manual, updated API reference pages, a revised specification, a changelog, release notes, and a runbook for the support team. That is tens of thousands of words, much of it repetitive scaffolding around the handful of facts that actually changed. Your hands carry the entire load, and by Thursday afternoon your wrists know it.

Dictation changes the math. You speak at 130 to 150 words per minute without trying; most people type somewhere between 40 and 80. For the prose-heavy parts of technical writing (the overviews, the step descriptions, the "why this matters" paragraphs), talking is simply faster than typing, and it spreads the physical effort away from your fingers. The catch is that technical writing is not pure prose. It is prose wrapped around code blocks, parameter tables, exact casing, and unforgiving jargon. Dictation that works for a journal entry can fall apart on a sentence like "set maxRetries to 3 before calling POST /v2/jobs."

This guide is about making dictation actually work for the documents technical writers produce. We will cover which parts of the job to dictate, which parts to keep on the keyboard, and the specific techniques that keep voice input from mangling your terminology. Most of it applies to any serious dictation tool, and we will show how Voice Keyboard Pro handles the technical-writing-specific friction points.

Why technical writers are turning to voice

Three pressures push technical writers toward dictation. The first is volume. Documentation never shrinks; every feature adds pages and every deprecation adds migration notes. The second is repetitive strain. Writers who spend six or seven hours a day at a keyboard are squarely in the population most likely to develop wrist and hand problems, and once symptoms appear, cutting keystrokes stops being optional. The third is the simple speed gap: when you already know what a paragraph needs to say, dictating it and lightly editing is faster than typing it cold.

There is also a quality argument that surprises people. Technical prose has a tendency to become stiff and overloaded when typed, because typing is slow enough that you pack every clause into one sentence to avoid retyping. Dictation nudges you toward shorter, more spoken sentences, which are usually clearer for the reader trying to follow a procedure. If you have ever read a setup guide and gotten lost in a 60-word sentence, you have met the problem that voice quietly fixes.

What to dictate and what to keep on the keyboard

The single most important habit is knowing the boundary. Trying to dictate everything, including curly braces and camelCase identifiers, will frustrate you. Trying to type everything wastes the speed advantage. Draw the line like this:

Dictate the prose layer:

Keep on the keyboard:

In practice the workflow becomes a rhythm: dictate a paragraph of explanation, drop to the keyboard to paste or type the code sample, dictate the paragraph that explains the code, and move on. You are not choosing voice or keyboard. You are using each for what it is best at, and the hand-intensive portion of your day shrinks dramatically. Writers who document code specifically should also read our guide on how to dictate code comments, which goes deeper on the prose-around-code pattern.

Dictating the four core document types

User manuals and how-to guides

Manuals are the friendliest document type for voice because they are mostly numbered steps written in plain language. The trick is to dictate the action and the result as one spoken unit: "Click the Settings icon in the top right corner, then choose Account from the menu that appears." Say the period at the end of each step so the structure stays clean. When you reference a literal button label or menu name, just speak it normally and capitalize during editing, or store the common ones in your dictionary so they come out capitalized automatically.

For the screenshots-and-captions pattern, dictate the caption text first and place the images afterward. Trying to interleave figure references while you talk breaks your flow; write all the words, then drop in the visuals.

API documentation

API reference pages are the hardest case, and the honest answer is that you split them. The descriptive fields (the one-line summary of what an endpoint does, the human explanation of each parameter, the notes about rate limits and error codes) are pure prose and dictate beautifully. The signature itself, the path, the request and response bodies, and the type names belong on the keyboard or pasted from your code.

So for an endpoint you might dictate: "This endpoint creates a new export job and returns its identifier. The job runs asynchronously, so poll the status endpoint until it reports complete." Then you type the POST /v2/exports line and the JSON body by hand. The ratio of words you dictate to characters you type is heavily in favor of voice, which is the whole point. Store recurring type names and endpoint nouns in a custom vocabulary so that when you do mention them in prose, they come out right.

Specifications and PRDs

Specs are almost entirely prose and reasoning, which makes them ideal for dictation. The "background," "goals," "non-goals," "proposed approach," and "open questions" sections are exactly the kind of structured argument that flows well when spoken. Many writers find that dictating a spec produces a more honest first draft, because talking through a design forces you to say the parts you would have glossed over while typing. Dictate the whole thing loosely, then return with the keyboard to add the diagrams, tables, and links.

Release notes and changelogs

Release notes are short, high-frequency, and perfect for voice. The format is predictable, just a verb, a feature, and a benefit, so you can rip through a dozen entries by speaking. "Fixed an issue where exports larger than 500 megabytes would time out. Added support for filtering results by date range. Improved the loading speed of the dashboard on slower connections." Because these go out constantly, shaving the typing off each one adds up fast over a year.

Taming jargon: the custom dictionary is everything

Generic dictation tools will reliably mangle your product vocabulary. They will write "Coober Netties" for Kubernetes, "post grey sequel" for PostgreSQL, and turn your product name into three different misspellings on the same page. This is the number one reason technical writers abandon voice, and it is completely fixable.

The fix is a custom dictionary with replacement rules. In Voice Keyboard Pro, the Smart Vocabulary feature lets you add the terms you use constantly (product names, internal service names, acronyms, SDK method names, the spelling your style guide demands) and define how they should appear. Once "kubernetes" is in your dictionary spelled correctly, the engine stops guessing. The same mechanism handles your house style: if your guide says "log in" as a verb and "login" as a noun, or insists on "email" with no hyphen, you can encode those preferences so you stop fixing them by hand on every document.

Spend twenty minutes seeding the dictionary before your first real session. List every term that appears in your docs that a stranger would not know how to spell, plus your top ten product and feature names. That single setup step is the difference between fighting your transcription and trusting it. Our broader guide for voice to text for technical writers walks through building a documentation vocabulary in more detail.

Punctuation, structure, and formatting by voice

Technical writing lives and dies on structure, so you need to control it while dictating. The good news is that you can speak most of it. Say "period," "comma," "colon," "open paren" and "close paren," "new line," and "new paragraph" and they appear as the characters and breaks you mean. For numbered procedures, dictate the sentence and add the list numbering during a quick keyboard pass, or use your editor's auto-numbering so you only speak the step text.

A reliable pattern for headings: dictate the heading text on its own line, then add the Markdown # markers or apply the heading style afterward. Trying to dictate "hash hash space" inline works but interrupts your thinking; most writers prefer to speak clean text and apply structure in a fast formatting pass. The mental model that helps is to separate composing from formatting. Get the words down by voice, then shape them with the keyboard. You will be faster than doing both at once, and your prose will be better for not being interrupted every line by syntax.

Fixing mistakes without breaking flow

Every dictation session produces a few wrong words: a misheard term, a homophone, a name that came out phonetically. The slow way to fix them is to stop, grab the mouse, click into the word, delete, and retype. The fast way is to keep talking and clean up in one editing pass at the end, the same way you would proofread typed text.

On iPhone, Voice Keyboard Pro adds a faster option: Voice Edit lets you speak the correction itself. You can say something like "change maxRetry to maxRetries" and the keyboard makes the edit in place, which is genuinely useful when you are documenting on the go and do not want to fiddle with cursor placement on a touchscreen. On the Mac, the typical flow is dictate-then-proofread, which keeps your composing speed high and batches the corrections so they do not fracture your concentration.

A documentation workflow that actually holds up

Here is a workflow that technical writers settle into after a week or two:

  1. Outline by voice. Dictate your section headings and a one-line intent for each. This is fast and gets the skeleton down before you lose the thread.
  2. Draft the prose layer. Go section by section, dictating the explanatory paragraphs and step text. Do not stop for code or formatting; leave placeholders like "CODE HERE" you can search for later.
  3. Fill the technical layer with the keyboard. Now paste or type the code samples, signatures, tables, and config. This is focused keyboard work, but it is a fraction of the total keystrokes.
  4. Format and link. Apply headings, lists, and inline code styling. Add cross-links and figure references.
  5. Proofread once. Read it through and fix the handful of misheard words. Add any new terms you tripped over to your dictionary so next time they are correct.

The compounding benefit is in that last step. Every document makes your dictionary smarter, so accuracy climbs over weeks until misrecognitions are rare. Writers who maintain large documentation sets often pair this with a project-level glossary; if that is you, our guide on dictation for project documentation covers keeping terminology consistent across a whole docs repository.

Working across Mac and iPhone

Most technical writing happens at a desk, and that is where the Mac app shines. Voice Keyboard Pro lives in your menu bar; you hold a hotkey, speak, release, and the text lands at your cursor in whatever app you are using: your Markdown editor, the docs CMS, a pull-request description, a code review comment. Because it works system-wide, you are not locked into one writing tool, and you do not paste between a separate transcription window and your editor.

The iPhone keyboard covers the in-between moments: capturing a doc idea on your commute, replying to a reviewer's comment, jotting down a bug repro before you forget it. The built-in mic button means you dictate directly into any app without switching keyboards. For writers who document inside a code editor, our walkthrough on voice to text in VS Code shows the desktop setup in a real editor.

A note on privacy

Technical documentation often describes unreleased features, internal architecture, and security-sensitive configuration. That makes privacy a real concern, not an afterthought. Voice Keyboard Pro's servers store only operational pings — the lightweight signals needed to keep the service running. Your audio and the text you dictate are not retained on the server. For documentation that touches confidential systems, that distinction matters, and it is worth confirming the same about any dictation tool before you trust it with a draft of your next release.

Frequently asked questions

Can dictation handle code-heavy documentation?

It handles the prose around the code excellently and the code itself poorly, which is exactly the right division of labor. Dictate every explanation and instruction; type or paste the literal code. You will still cut the majority of your keystrokes because most documentation is words, not symbols.

How do I stop it from misspelling our product names?

Add them to a custom dictionary with the exact spelling you want. Once a term is stored, the engine uses your spelling instead of guessing phonetically. This is the most important setup step for technical writers.

Is voice fast enough to be worth changing my workflow?

Speaking runs at 130 to 150 words per minute against 40 to 80 for typing, and the prose layer of documentation is where you spend most of your words. Even accounting for an editing pass, the net throughput gain is large, and the reduction in hand strain is often the bigger win.

Get started

If you write documentation for a living, the fastest improvement you can make this week is to stop typing the parts of it that are just words. Draft by voice, type the code, and let a custom dictionary handle your jargon. Voice Keyboard Pro has a free tier on both Mac and iPhone, so you can dictate your next set of release notes and feel the difference before you commit to anything. Your wrists, and your reader who finally gets a sentence they can follow, will both thank you.