Documentation is the task everyone postpones. Voice dictation makes it fast enough that you actually do it.
Documentation is universally acknowledged as important and universally avoided as tedious. The reason is simple: writing docs feels like work that produces no immediate value. The feature is already built, the API already works, and the team already understands the code. Writing it all down for future readers feels like a chore. But documentation debt compounds over time, and the cost of not having docs always exceeds the cost of creating them.
Voice dictation cuts the creation cost dramatically. When you can explain a feature by simply talking about it, documentation becomes as easy as a conversation. With Steno, you hold a hotkey, describe how something works, release, and the text appears in your document. No context switching, no staring at a blank file wondering where to start. You already know how the feature works; you just need to say it.
Good documentation reads like someone explaining something clearly. That is exactly what speaking produces. When you dictate documentation, you naturally use the same explanatory tone that makes docs useful: direct, sequential, and focused on the reader's understanding. Typed documentation often suffers from either over-engineering (too formal, too abstract) or under-writing (too terse, too many gaps). Spoken documentation tends to hit the right level of detail because you are simulating an actual explanation.
There is another advantage specific to technical documentation. Developers who write the code are the best people to document it, but they are also the people least motivated to do so. Voice dictation lowers the activation energy enough that the person who built the feature can document it in 5 minutes instead of dreading it for a week. That freshness also improves quality, because the implementation details are still top of mind.
1 Open your documentation file
Whether it is a README.md in your repository, a wiki page in Notion or Confluence, a page in GitBook, or a Google Doc shared with your team, open it and place your cursor where you want to start writing. Steno works in all of these because it inserts text at the cursor position using macOS accessibility APIs.
2 Type your section headings first
Use the keyboard to create your document skeleton: section headings, subheadings, and any structural elements like Markdown headers or numbered sections. This takes 2 to 3 minutes and gives you a clear structure to fill in. A typical README might have: Overview, Installation, Quick Start, Configuration, API Reference, Troubleshooting, and Contributing. For Markdown files, type the ## headers directly since typing syntax characters is faster than dictating them.
3 Dictate the overview section
Place your cursor under the first heading. Hold the Steno hotkey and explain what the project or feature does as if you were telling a new team member about it. Focus on the "what" and "why" before the "how." This section sets the context for everything that follows. Speak for 20 to 40 seconds and release the hotkey. Review what appeared and make minor tweaks if needed.
4 Fill in each section with voice
Move through your document section by section. For each heading, hold the hotkey and explain that topic. Installation? Describe the steps someone needs to follow. Configuration? Explain each option and what it controls. Troubleshooting? Talk through the common problems you have seen and how to fix them. Between sections, use the keyboard to add code blocks, links, and formatting that are easier to type than speak.
5 Add code examples with keyboard
Switch to typing for any code examples, terminal commands, or configuration snippets. These require precise syntax that is better typed than dictated. The hybrid approach — voice for prose, keyboard for code — plays to the strengths of each input method and produces documentation that is both comprehensive and accurate.
6 Review and format
Read through the full document. Fix any transcription issues, ensure consistent terminology, add links to related documentation, and verify that code examples are correct. This pass typically takes 5 to 10 minutes for a standard README and ensures professional quality output.
"Steno is a native macOS menu bar application that converts speech to text in real time. It works in any application on your Mac. Hold a hotkey, speak, and release. Your spoken words appear as text at the cursor position. It uses Groq Whisper for transcription, which provides high accuracy for both conversational speech and technical vocabulary."
Output: Steno is a native macOS menu bar application that converts speech to text in real time. It works in any application on your Mac. Hold a hotkey, speak, and release. Your spoken words appear as text at the cursor position. It uses Groq Whisper for transcription, which provides high accuracy for both conversational speech and technical vocabulary.
"The register endpoint accepts a POST request with the device ID and platform in the request body. It returns a JSON response containing the API key and device token. The API key should be stored securely in the macOS Keychain and included as a bearer token in all subsequent requests."
Output: The register endpoint accepts a POST request with the device ID and platform in the request body. It returns a JSON response containing the API key and device token. The API key should be stored securely in the macOS Keychain and included as a bearer token in all subsequent requests.
"If the microphone permission dialog does not appear on first launch, go to System Settings, then Privacy and Security, then Microphone, and manually toggle the switch for Steno. This can happen if the app was previously installed and the permission state was cached by macOS."
Output: If the microphone permission dialog does not appear on first launch, go to System Settings, then Privacy and Security, then Microphone, and manually toggle the switch for Steno. This can happen if the app was previously installed and the permission state was cached by macOS.
Document right after building. The best time to document a feature is immediately after shipping it. The implementation is fresh in your mind, edge cases are top of awareness, and you have not yet moved on to the next task. With Steno, "documenting right after building" takes 5 to 10 minutes instead of an hour, so there is no reason to delay. For more ways developers use voice in their workflow, see our blog post on 5 ways developers use voice-to-text daily.
Pretend you are onboarding someone. The best documentation reads as if a knowledgeable team member is walking you through the system. When you dictate, imagine you are sitting next to a new hire explaining the project. This mental model naturally produces the right level of detail, the right assumptions about prior knowledge, and the right order of information.
Use the "explain, then example" pattern. For each section, first dictate the explanation of what something does and why. Then switch to keyboard to add a concrete code example. This voice-then-keyboard rhythm keeps you moving quickly through the document while maintaining technical precision where it matters.
Batch your documentation sessions. Instead of documenting features one at a time, set aside 30 minutes and document three to five features in a row. The momentum of voice dictation makes batch sessions highly productive. You can cover an entire module's documentation in a single focused session. For tips on structuring these sessions, check out our guide on brainstorming with voice.
A typical README file with 800 to 1,200 words of prose content:
More importantly, the psychological barrier drops to near zero. When documentation takes 25 minutes instead of an hour, you actually do it. The compound effect of consistently documented features is transformative for team velocity and onboarding speed. Learn more about how Steno processes your speech to understand the technology behind accurate transcription.
It is more practical to dictate the prose content with voice and add Markdown syntax like headers, code blocks, links, and bullet points with the keyboard. This hybrid approach is faster and more accurate than trying to speak formatting characters. Most documentation workflows naturally separate content creation from formatting anyway.
Explanatory content works best: getting started guides, architecture overviews, feature descriptions, troubleshooting guides, and onboarding documents. API reference documentation with precise parameter names and types is better typed directly. The sweet spot is any documentation that requires you to explain how or why something works.
Imagine explaining every section to the same person. This creates natural consistency in vocabulary, formality level, and detail depth. A light editing pass after dictation ensures uniform tone across all sections. Most writers find that voice-dictated docs have a more consistent, conversational tone than docs written in multiple typed sessions over several days.
Yes. Steno works in any text field on macOS, including Notion, Confluence, GitBook, Google Docs, Dropbox Paper, and plain text editors where you write Markdown source files. It inserts text at the cursor position regardless of the application, so your existing documentation workflow does not need to change.
With Steno, writing docs is as easy as explaining your feature out loud. Download it now and document something today.
Download Steno for Mac