Measure the keystrokes you actually replace, not whether the app worked

RSI is what you get when typing volume, frequency, or both exceed what a wrist can sustain. The fix for that injury is rest, ergonomic adjustments, and whatever else a professional treating it recommends — this page is not going to claim that a software tool is one of those things. What it can do is reduce the keystrokes for the writing you choose to dictate instead of type. That is a narrower claim, and it is the only one this page makes.

The trap most people fall into is testing dictation on a single sentence or a demo prompt and calling it useful if the sentence lands right. What actually matters is whether the volume of typing that gets replaced is large enough to affect a day that is already causing pain. That question only has an answer after a real week of work, not a demo.

What typing volume actually piles up

Not usually the short messages. A day with ten Slack replies, two emails and some notes feels like ordinary work; what it adds up to is dozens of replies that never would have been sent if they required a formal email instead — because chat is typed reply after reply, all day, on top of whatever other writing is happening. Someone who spends an hour on Slack is not usually aware that hour was spent typing, one message after another, until it is time to notice the wrist complaining.

The ones where dictation saves time are the ones where the thinking is done and what remains is transcription: a paragraph of documentation that already exists in rough form, a Slack reply to a message you understood immediately, an email answering a straightforward question. Compose-as-you-go writing, where the sentence is being decided while it is being typed, often goes just as fast typed as dictated, and sometimes faster.

The honest measurement is not "did this work" but "how much of this week's actual typing volume moved to speech." That is the only number that tells you whether the time investment in building the habit pays off for your specific workflow.

Where the keystrokes come from if you track them

Spend a week using dictation for whatever tasks feel natural and not forcing anything. At the end of the week, write down:

• How many longer messages (email, documentation, Slack replies over a few lines) you dictated instead of typed
• How many short ones you typed anyway because they were faster
• Which tasks you did not dictate because they were not worth it — code, configuration, editing existing text
• How many times you had to edit a dictation after it landed because the engine misheard something

The result is not a scientific measurement; it is a rough count of real work. If you spent a week dictating half your Slack replies and all your longer emails but typing all your short messages and your code, you have a concrete sense of what this tool does and does not do in your actual workflow. Nobody can tell you that number in advance; only real work reveals it.

Identifying what can move to speech

Start by looking at a single day and asking: what writing happened today that could just as easily have been said? Not "what would be faster to dictate," but "what would sound natural said aloud instead of typed." Those are usually longer, less formal, more thought-out-as-you-go kinds of writing:

• A Slack message answering a question you understood immediately
• An email to a colleague about something you are both already thinking about
• Documentation explaining a decision or a process
• A chat message in a support channel answering a customer question
• Notes on a meeting or a decision
• A follow-up message pointing to a resource or a link

All of these make sense said aloud instead of typed. They are also usually the ones long enough that the typing volume adds up. A day that includes three of those instead of typed will have somewhere between fifty and two hundred fewer keystrokes, depending on how long they are — not a huge difference, and not the whole day, but a real measurable one.

By contrast, the things that usually do not make sense to dictate are:

• Code, configuration or anything with syntax
• Heavily edited text, where you are trying four variations of one sentence
• Very short messages — one or two sentences
• Anything where you are transcribing from another source word-for-word

Those stay typed. The point is not to replace everything but to replace what you can replace, and the rest stays the way it already works.

The actual replacement: hold a hotkey, dictate, let go

Once you have identified what moves to speech, the mechanism is simple: whenever you would have typed one of those things, hold ⌥ Space (or whatever hotkey you have configured) instead, say the message, let go, and the words land in whatever app was open.

The text lands exactly as you said it, without rewriting, because this app types exactly what you said, not a tidied version of it. That means your filler words come through if they came out, and anything you wanted in the message stays the way you wanted it phrased.

Building a habit around when to dictate

The first few dictations feel awkward because the instinct to type is strong and dictating feels like a step to remember to take. It usually becomes invisible somewhere around the fifth or sixth time you do it in a day, when pressing the hotkey stops being a decision and just becomes what you do when you want to talk instead of type.

What varies between people is how much of their day's typing actually gets replaced. Someone who writes mostly long-form email might replace forty percent of keystrokes by moving to dictation; someone whose day is short Slack messages and code might replace five percent and find it is not worth the habit. The only way to know is to build it and measure.

When in doubt, test it in the actual moment

If a message feels like it might dictate faster than it would type, try dictating it. If it feels like typing is faster, type it. You do not have to be consistent within a day or within a conversation thread — you can switch between the two without any penalty. The choice that works best in the moment is the right choice for that specific message.

As the habit develops, the switch becomes less obvious because it is happening more often, but there is never a penalty for choosing the slower path if that is what feels right for a particular message.

Reading back what landed

The moment between dictating and sending is the moment to read what landed. A misheard word in a Slack message is just a typo and an immediate correction; a misheard word in an email to a client or a support response matters more. Take ten seconds, read, and decide whether to send as-is, edit, or dictate fresh.

This is not extra overhead; it is the same instinct anyone already has for reading a message before sending, applied to a dictated one instead of a typed one.

What does not change

Dictation removes keystrokes for the writing part. It does not remove the mouse or trackpad use, the clicking through forms, the scrolling through pages, the time spent thinking about what to say. If the mouse causes as much strain as the keyboard, or if the thinking is the bottleneck, reducing typing alone will not change much.

The comparison of accessibility tools covers the broader case where full hands-free control of the Mac is the need, and names the tools built for that. This page is narrower: it is about reducing typing, which is one tool addressing one part of what a day at a computer includes.

Pacing, not just volume

Reducing the number of keystrokes is one measurement; reducing continuous, unbroken typing time is a different one. Someone who dictates a long document in a handful of long stretches has removed a lot of keystrokes but may still be holding a key down for extended periods without a break — different muscle groups, but still repetitive, still tiring.

If continuous typing is part of what causes strain, building in short pauses between dictations — the same kind of pacing a professional might already recommend for any repetitive activity — is worth doing deliberately rather than assuming a tool that reduces typing automatically also improves pacing.

Measuring over a month, not a week

The single week is the proof of concept: does the thing work, can the habit form, is the volume real. But whether using it for a month or two actually reduces strain enough to matter in the rest of the day is a question only a longer trial answers. The thirty-day free trial is built long enough to find out whether real work over several weeks shows a difference worth continuing, not just whether the mechanism works when tested.

Privacy and nothing going upstream

Every dictated message stays on the machine it was dictated on. Nothing is uploaded — no audio, no transcript, and the app works with no internet connection at all. That is a privacy property first, but it is also a practical one: a message about a medical issue, an insurance matter, or anything personal stays on the machine and never needs to exist on a server.

Tracking progress without stress

Some people find it useful to count keystrokes at the end of a day or a week, just to have a concrete number. Most people just notice when they have been talking more and typing less, and find that their hand hurts a little less at the end of the day. The first is more scientific; the second is more usable. Either one works.

Different workflows have different savings

Developers might find that only commit messages and PR descriptions benefit from dictation, while the code itself stays typed — a smaller savings than someone whose day is mostly Slack and email. Someone writing long-form content might replace fifty percent of keystrokes, while someone whose Slack replies are usually one sentence will replace much less. The measurement is personal; only real work shows what your savings actually are. This is why the test is not a single dictation but a full week of actual work — the volume difference between roles is usually larger than the difference between "dictation works" and "dictation does not work" for any individual person.

When to try it, when to skip it

If a meaningful share of a day's typing is long-form writing — email, Slack, notes, documentation — that could just as easily be said instead of typed, the thirty-day trial is long enough to find out whether that volume actually moves, and whether the reduction matters for your specific day.

If most of your typing is short messages, code, or heavily edited text, the payoff is smaller and the habit might not be worth building.

If the pain is in the shoulder, neck, or forearm instead of the wrist, or if the problem is the mouse rather than the keyboard, a reduced-typing tool addresses a different part of the problem than what is causing strain.

The built-for pages show how different jobs use dictation differently — some roles have obvious places for it, others less so. If your role is mostly writing or takes communication seriously, the payoff is worth testing. If you spend your typing time on something dictation cannot handle, the payoff is smaller.

None of this is medical advice. What it is is a practical guide to testing whether reducing your typing volume with speech would measurably change your workflow. The only way to know is to try it against real work over real time, and the thirty-day trial exists exactly for that test.