Workflow voice first: una giornata nel nostro lavoro voice-first

Sono Shuran, founder di Loqua.ai. Questa è la versione onesta del nostro workflow voice first: dove fa risparmiare tempo, dove fallisce e cosa faccio invece. L'obiettivo non è esibire produttività. L'obiettivo è ridurre la distanza tra un pensiero e l'artefatto che porta avanti il lavoro. Alla fine di una giornata come questa, la domanda digitare-versus-parlare e quasi invisibile; noto il lavoro stesso.

Inbox delle 8

Inizio con Spark Mail e Slack. La voce funziona bene qui perché le risposte sono soprattutto intento e tono. Detto la risposta grezza, Loqua rimuove i riempitivi, e il livello consapevole dell'app mantiene l'output più breve in Slack che in email.

Il blocco inbox di solito prende quindici o venti minuti. Circa due terzi delle risposte sono dettati; il resto e digitato perché richiede parole esatte, una lista di link o una spiegazione delicata. La divisione non è una regola. E ciò che diventa la mattina quando smetto di forzare uno strumento a fare il lavoro dell'altro.

Dove la voce fallisce: thread confidenziali in spazi pubblici. Se sono in un bar e il messaggio contiene contesto sensibile, digito. Voice first non significa privacy second.

Standup

Per lo standup, pronuncio tre slot: shipped, today, blocker. E uno dei pattern di workflow di digitazione vocale quotidiana con il ritorno più alto, perché la struttura si ripete e il contenuto cambia.

Il trucco è non divagare. Dico ad alta voce i nomi degli slot. Loqua li usa come struttura. Scrivere lo standup richiede forse trenta secondi, più un altro minuto per leggere cosa ha postato il resto del team. La voce non fa risparmiare tantissimo su ogni standup singolo; fa risparmiare il costo di rimandarlo, che prima era il freno più grande della giornata.

Code review

La code review e mista. La voce è ottima per spiegare la preoccupazione; tastiera e mouse sono migliori per la precisione a livello di riga. Detto riepiloghi di review e commenti di alto livello, poi uso mouse e tastiera per navigare con esattezza nei file.

Un buon commento di review vocale dice perché il problema conta, non solo quale riga e sbagliata. Per esempio: "This cache key ignores locale, so Chinese and English results can collide. Can we include locale in the key and add a regression test?" Quel commento e molto più facile da dire che da digitare mentre leggi codice.

Bozza di spec

La stesura di spec e il punto in cui il workflow voice first sembra più vicino al pensiero. Detto goal, non-goal, user flow, edge case e criteri di accettazione. Poi modifico gli heading con la tastiera. Per una spec più grande parto in Obsidian; per task implementativi sposto la versione ripulita in Claude Code o Cursor.

La prima bozza dettata raramente e la spec che consegniamo. E lo scaffold che rende ovvio l'editing con la tastiera. Il trucco che continuo a reimparare e che la versione dettata fa emergere le sezioni mancanti più velocemente di un outline digitato, perché dire "acceptance" ad alta voce mi obbliga a far seguire almeno un criterio.

Thread Slack

Slack e il luogo in cui il tono conta. La voce può sembrare troppo brusca se il modello di cleanup si limita a trascrivere. La formattazione per destinazione di Loqua mantiene le risposte brevi ma non fredde. Rileggo comunque prima di inviare; la voce deve accelerare il giudizio, non sostituirlo.

Un pattern che ho imparato con il tempo: detta la versione calda, non quella efficiente. Slack si legge meglio quando la prima frase riconosce la persona e la seconda arriva al punto. Una risposta digitata tende a saltare la prima frase. Una dettata di solito la mantiene, e il thread ne esce più sano.

Dove la voce fallisce: quando un thread richiede citazioni precise o molti link. Li digito. La regola ibrida e semplice: usa la voce per l'argomento, la tastiera per i riferimenti.

Diario di fine giornata

A fine giornata detto ciò che mi ha sorpreso. Non e uno status update. E cattura della memoria: cosa mi ha fatto cambiare idea, cosa è stato più difficile del previsto e cosa non devo dimenticare domani. Obsidian e la destinazione perché e cercabile e collegabile.

Una voce di diario tipica e lunga tre paragrafi brevi e richiede circa cinque minuti. Il pattern interessante e che le voci più preziose riguardano le piccole sorprese, non le grandi decisioni. Le grandi decisioni vengono comunque scritte, spesso più di una volta. La piccola sorpresa, l'API che ha risposto in una forma diversa da quella implicata dai docs, il commento utente che ha contraddetto il mio modello, e quella che sparisce entro la mattina se non viene catturata.

Quando oggi la voce non ha funzionato

Due esempi dalla stessa giornata. Primo, un refactor di codice denso in un file affollato. Ho provato a dettare il piano di rinomina nell'editor e il modello continuava a sbagliare un identificatore perché il contesto visibile scorreva più rapidamente di quanto il listener potesse seguirlo. Sono passato alla tastiera. La voce era lo strumento sbagliato perché il cursore si muoveva troppo velocemente per stabilizzare il contesto.

Secondo, un thread Slack teso in cui la risposta giusta era di tre frasi e zero aggettivi. Ho dettato, il cleanup ha aggiunto una piccola attenuazione cortese e il messaggio e risultato più morbido di quanto volessi. L'ho riscritto a mano. La lezione e che la voce è buona per il calore e cattiva per la freddezza deliberata; quando serve un messaggio piatto, digita.

Per dettagli più ampi sullo stack, vedi il nostro voice productivity stack. Per l'argomento dietro l'abitudine, vedi perché la tastiera e lo strumento sbagliato per pensare con l'AI. I riferimenti esterni che hanno influenzato il nostro workflow Mac includono Apple Dictation e la documentazione Linear.