Voice-First-Workflow: ein Tag in unserem voice-first Arbeitsalltag

Ich bin Shuran, Gründer von Loqua.ai. Das ist die ehrliche Version unseres Voice-First-Workflows: wo er Zeit spart, wo er versagt und was ich stattdessen mache. Das Ziel ist nicht, Produktivität zu inszenieren. Das Ziel ist, den Abstand zwischen einem Gedanken und dem Artefakt, das die Arbeit voranbringt, zu verkürzen. Am Ende eines Tages wie dieser ist die Frage Tippen-versus-Sprechen meist unsichtbar; was ich wahrnehme, ist die Arbeit selbst.

Posteingang um 8 Uhr

Ich starte mit Spark Mail und Slack. Sprache funktioniert hier gut, weil Antworten meist aus Intent und Ton bestehen. Ich diktiere die grobe Antwort, Loqua entfernt Füllwörter, und die app-bewusste Schicht hält das Ergebnis in Slack kürzer als in E-Mail.

Der Posteingangs-Block dauert meist fünfzehn bis zwanzig Minuten. Etwa zwei Drittel der Antworten werden diktiert; der Rest wird getippt, weil sie exaktes Wording, eine Liste von Links oder eine heikle Erklärung brauchen. Die Aufteilung ist keine Regel. Sie ergibt sich, sobald ich aufhöre, ein Tool die Arbeit des anderen machen zu lassen.

Wo Sprache versagt: vertrauliche Threads in öffentlichen Räumen. Wenn ich im Café sitze und die Nachricht sensible Inhalte hat, tippe ich. Voice first heißt nicht Datenschutz an zweiter Stelle.

Standup

Für den Standup spreche ich drei Slots: geliefert, heute, Blocker. Das ist eines der ertragreichsten Muster im täglichen Spracheingabe-Workflow, weil sich die Struktur wiederholt und nur der Inhalt wechselt.

Der Trick ist, nicht abzuschweifen. Ich spreche die Slot-Namen laut aus. Loqua nutzt sie als Struktur. Der Standup selbst braucht vielleicht dreißig Sekunden zum Schreiben und eine weitere Minute, um zu lesen, was der Rest des Teams gepostet hat. Sprache spart bei jedem einzelnen Standup nicht viel Zeit; sie spart die Kosten des Aufschiebens, was früher die größere Bremse im Tag war.

Code Review

Code Review ist gemischt. Sprache ist hervorragend, um das Anliegen zu erklären; die Tastatur ist besser für zeilengenaue Präzision. Ich diktiere Review-Zusammenfassungen und High-Level-Kommentare, dann nutze ich Maus und Tastatur für die exakte Datei-Navigation.

Ein guter Sprach-Review-Kommentar sagt, warum das Problem zählt, nicht nur welche Zeile falsch ist. Zum Beispiel: „Dieser Cache-Key ignoriert die Locale, also können chinesische und englische Ergebnisse kollidieren. Können wir die Locale in den Key aufnehmen und einen Regressionstest ergänzen?" Diesen Kommentar zu sprechen ist deutlich einfacher, als ihn beim Lesen von Code zu tippen.

Spec-Entwurf

Beim Spec-Entwurf fühlt sich der Voice-First-Workflow dem Denken am nächsten an. Ich diktiere Ziel, Non-Goals, User Flow, Edge Cases und Akzeptanzkriterien. Dann bearbeite ich die Überschriften mit der Tastatur. Für eine größere Spec starte ich in Obsidian; für Implementierungsaufgaben verschiebe ich die bereinigte Version in Claude Code oder Cursor.

Der erste diktierte Entwurf ist selten die Spec, die wir ausliefern. Er ist das Gerüst, das die Tastatur-Edits offensichtlich macht. Was ich immer wieder neu lerne: Die diktierte Version legt fehlende Abschnitte schneller offen als eine getippte Outline, weil das laute Aussprechen von „Akzeptanz" mich zwingt, mindestens ein Kriterium folgen zu lassen.

Slack-Threads

In Slack zählt der Ton. Sprache kann zu schroff klingen, wenn das Cleanup-Modell nur transkribiert. Loqua's Ziel-Formatierung hält Antworten kurz, aber nicht kalt. Ich lese trotzdem vor dem Senden; Sprache soll das Urteil beschleunigen, nicht ersetzen.

Ein Muster, das eine Weile gedauert hat zu lernen: Diktiere die warme Version, nicht die effiziente. Slack liest sich besser, wenn der erste Satz die Person anerkennt und der zweite Satz zur Sache kommt. Eine getippte Antwort lässt den ersten Satz tendenziell weg. Eine diktierte behält ihn meist bei, und der Thread ist gesünder dafür.

Wo Sprache versagt: wenn ein Thread sorgfältige Zitate oder mehrere Links braucht. Die tippe ich. Die Hybridregel ist einfach: Sprache für die Argumentation, Tastatur für die Referenzen.

Tagesabschluss-Journal

Am Ende des Tages diktiere ich, was mich überrascht hat. Das ist kein Status-Update. Es ist Gedächtnis-Capture: was meine Meinung geändert hat, was schwieriger war als erwartet und was ich morgen nicht vergessen darf. Obsidian ist das Ziel, weil es durchsuchbar und verlinkbar ist.

Ein typischer Journaleintrag besteht aus drei kurzen Absätzen und dauert etwa fünf Minuten. Das interessante Muster ist, dass die wertvollsten Einträge von kleinen Überraschungen handeln, nicht von großen Entscheidungen. Die großen Entscheidungen werden ohnehin festgehalten, oft mehr als einmal. Die kleine Überraschung — die API, die in einer anderen Form zurückkam, als die Docs nahelegten, der Nutzerkommentar, der meinem Modell widersprach — ist die, die bis zum Morgen verschwunden ist, wenn sie nicht erfasst wird.

Wann Sprache heute nicht funktioniert hat

Zwei Beispiele vom selben Tag. Erstens, ein dichter Code-Refactor in einer vollen Datei. Ich habe versucht, den Umbenennungsplan in den Editor zu diktieren, und das Modell hat einen Bezeichner immer wieder falsch verstanden, weil der sichtbare Kontext schneller scrollte, als der Listener mitkommen konnte. Ich bin zum Tippen gewechselt. Sprache war das falsche Werkzeug, weil sich der Cursor zu schnell bewegte, um den Kontext stabil zu halten.

Zweitens, ein angespannter Slack-Thread, bei dem die richtige Antwort drei Sätze und null Adjektive war. Ich habe diktiert, das Cleanup hat eine höfliche Abschwächung hinzugefügt, und die Nachricht las sich weicher, als ich wollte. Ich habe sie von Hand umgeschrieben. Die Lektion ist, dass Sprache gut für Wärme und schlecht für bewusste Kühle ist; wenn du eine flache Nachricht brauchst, tippe sie.

Für weitere Stack-Details siehe unseren Voice-Produktivitäts-Stack. Für die Begründung hinter dieser Gewohnheit siehe warum deine Tastatur das falsche Werkzeug ist, um mit KI zu denken. Externe Referenzen, die unseren Mac-Workflow geprägt haben, sind unter anderem Apple Dictation und die Linear-Docs.