Voice first workflow: a day in our voice-first workday

I am Shuran, founder of Loqua.ai. This is the honest version of our voice first workflow: where it saves time, where it fails, and what I do instead. The goal is not to perform productivity. The goal is to reduce the distance between a thought and the artifact that moves work forward. By the end of a day like this one, the typing-versus-speaking question is mostly invisible; the work itself is what I notice.

8am inbox

I start with Spark Mail and Slack. Voice works well here because replies are mostly intent and tone. I dictate the rough answer, Loqua removes filler, and the app-aware layer keeps the output shorter in Slack than in email.

The inbox block usually takes fifteen to twenty minutes. About two-thirds of replies are dictated; the rest are typed because they need exact wording, a list of links, or a delicate explanation. The split is not a rule. It is what the morning ends up being once I stop forcing one tool to do the other tool's job.

Where voice fails: confidential threads in public spaces. If I am in a café and the message contains sensitive context, I type. Voice first does not mean privacy second.

Standup

For standup, I speak three slots: shipped, today, blocker. This is one of the highest-return daily voice typing workflow patterns because the structure repeats and the content changes.

The trick is not to ramble. I say the slot names out loud. Loqua uses them as structure. The standup itself takes maybe thirty seconds to write and another minute to read what the rest of the team posted. Voice does not save much time on each individual standup; it saves the cost of putting it off, which used to be the larger drag on the day.

Code review

Code review is mixed. Voice is excellent for explaining the concern; keyboard is better for line-level precision. I dictate review summaries and high-level comments, then use the mouse and keyboard for exact file navigation.

A good voice review comment says why the issue matters, not just what line is wrong. For example: "This cache key ignores locale, so Chinese and English results can collide. Can we include locale in the key and add a regression test?" That comment is much easier to speak than to type while reading code.

Spec draft

Spec drafting is where voice first workflow feels closest to thinking. I dictate goal, non-goals, user flow, edge cases, and acceptance criteria. Then I edit headings with the keyboard. For a larger spec, I start in Obsidian; for implementation tasks, I move the cleaned version into Claude Code or Cursor.

The first dictated draft is rarely the spec we ship. It is the scaffold that makes the keyboard editing obvious. The trick I keep relearning is that the dictated version surfaces missing sections faster than a typed outline would, because saying "acceptance" out loud forces me to follow it with at least one criterion.

Slack threads

Slack is where tone matters. Voice can sound too blunt if the cleanup model only transcribes. Loqua's destination formatting keeps replies short but not cold. I still read before sending; voice should accelerate judgment, not replace it.

One pattern that took a while to learn: dictate the warm version, not the efficient version. Slack reads better when the first sentence acknowledges the person and the second sentence gets to the point. A typed reply tends to skip the first sentence. A dictated one usually keeps it, and the thread is healthier for it.

Where voice fails: when a thread requires careful quoting or multiple links. I type those. The hybrid rule is simple: use voice for the argument, keyboard for references.

End-of-day journal

At the end of the day, I dictate what surprised me. This is not a status update. It is memory capture: what changed my mind, what was harder than expected, and what I should not forget tomorrow. Obsidian is the destination because it is searchable and linkable.

A typical journal entry runs three short paragraphs and takes about five minutes. The interesting pattern is that the most valuable entries are about the small surprises, not the big decisions. The big decisions get written down anyway, often more than once. The small surprise — the API that returned in a different shape than the docs implied, the user comment that contradicted my model — is the one that disappears by morning if not captured.

When voice didn't work today

Two examples from the same day. First, a dense code refactor in a busy file. I tried dictating the renaming plan into the editor and the model kept getting one identifier wrong because the visible context was scrolling faster than the listener could catch up. I switched to typing. Voice was the wrong tool because the cursor was moving too quickly for context to stabilize.

Second, a tense Slack thread where the right reply was three sentences and zero adjectives. I dictated, the cleanup added one polite hedge, and the message ended up reading softer than I wanted. I rewrote it by hand. The lesson is that voice is good for warmth and bad for deliberate coldness; when you need a flat message, type it.

For broader stack details, see our voice productivity stack. For the argument behind the habit, see why your keyboard is the wrong tool for thinking with AI. External references that shaped our Mac workflow include Apple Dictation and the Linear docs.