Un giorno ti svegli e scopri che il tuo modo di relazionarti con il mondo è cambiato.
Che qualcosa di semplice come pronunciare una frase, fare una domanda o esprimere un bisogno può improvvisamente diventare difficile.
In quei momenti la tecnologia smette di essere architettura, framework, performance o prodotto.
Diventa qualcosa di molto più semplice.
Un modo per provare a risolvere un problema che hai davanti.
È così che è nato VoceSguardo.
Non da una roadmap.
Non da una business idea.
Non dalla ricerca di un nuovo progetto personale.
È nato da un’esigenza concreta e urgente: permettere a una persona con difficoltà nella comunicazione verbale di costruire una frase attraverso lo sguardo e trasformarla in voce.
Alla fine non mi è servito.
Ed è probabilmente la cosa più importante che possa dire di questo progetto.
Ma anziché archiviarlo, ho deciso di lasciarlo qui.
Insieme a un abbraccio, nel caso in cui un giorno possa servire a qualcun altro.
Prima del software viene il problema
La prima tentazione, quando sei abituato a costruire software, è iniziare subito a pensare alla soluzione.
Interfaccia.
Framework.
Componenti.
Architettura.
Ma in questo caso la domanda iniziale era molto più elementare:
come può una persona scrivere una frase se non riesce a utilizzare normalmente una tastiera?
Lo sguardo era una possibilità.
Da lì nasce l’idea di una tastiera controllata attraverso eye tracking, in cui il movimento degli occhi permette di spostarsi tra lettere e parole.
Ma muovere un cursore non basta.
Serve anche un modo per dire:
“voglio selezionare proprio questo elemento.”
Ed è qui che un problema apparentemente semplice ha iniziato a trasformarsi in una serie di decisioni di progettazione.
Lo sguardo come interfaccia
Il dispositivo disponibile era un tablet Android.
La soluzione doveva quindi utilizzare ciò che avevo già a disposizione, evitando per quanto possibile hardware specialistico.
L’obiettivo era costruire un’interazione essenziale:
sguardo → elemento della tastiera → selezione → frase → voce
La fotocamera frontale osserva il volto.
Il sistema prova a stimare la direzione dello sguardo.
La posizione viene tradotta nelle coordinate dell’interfaccia.
Un cursore evidenzia l’area che il sistema ritiene stia osservando l’utente.
La tastiera diventa così uno spazio navigabile senza toccare lo schermo.
Sulla carta sembra lineare.
Nella pratica, ogni passaggio introduce incertezza.
Il problema non è vedere gli occhi. È capire dove stanno guardando.
Un sistema di eye tracking non deve semplicemente riconoscere la presenza degli occhi.
Deve trasformare una stima geometrica in una posizione sufficientemente precisa sullo schermo.
E persone diverse guardano lo stesso punto in modi leggermente diversi.
Cambiano:
- posizione del volto;
- distanza dal dispositivo;
- inclinazione della testa;
- caratteristiche degli occhi;
- condizioni di illuminazione;
- posizione del tablet.
Per questo è necessaria una fase di calibrazione.
L’utente osserva una sequenza di punti conosciuti sullo schermo.
Il sistema confronta ciò che rileva con la posizione reale del punto.
Da queste osservazioni costruisce la trasformazione utilizzata successivamente per stimare dove sta guardando la persona.
Nel prototipo siamo arrivati a un errore di calibrazione nell’ordine del 9%.
Non è la precisione di un dispositivo professionale dedicato.
Ma era sufficiente per continuare a sperimentare sull’interazione.
Guardare non significa necessariamente scegliere
Risolto — almeno parzialmente — il movimento del cursore, emerge immediatamente un secondo problema.
Se ogni elemento osservato venisse automaticamente selezionato, utilizzare la tastiera diventerebbe quasi impossibile.
Gli occhi si muovono continuamente.
Guardiamo una lettera.
Poi quella accanto.
Poi torniamo indietro.
Il sistema deve quindi distinguere tra:
navigazione
e
intenzione.
Ho valutato diverse modalità di selezione.
Una permanenza prolungata dello sguardo su un elemento è una soluzione intuitiva, ma può rallentare molto l’interazione e produrre selezioni involontarie.
Nel caso specifico, la soluzione che risultava più naturale era utilizzare l’apertura della bocca come gesto di conferma.
Lo sguardo decide dove.
Il gesto decide quando.
Due segnali differenti per due intenzioni differenti.
È un piccolo dettaglio di interazione, ma cambia radicalmente l’esperienza.
Una tastiera non basta
Una volta selezionabili le lettere, il problema successivo diventa la velocità.
Scrivere carattere per carattere attraverso lo sguardo è inevitabilmente più lento rispetto a una tastiera tradizionale.
Per questo VoceSguardo ha iniziato a incorporare anche il completamento delle parole.
Mentre l’utente compone il testo, il sistema può proporre parole compatibili con ciò che è già stato scritto.
La selezione di un suggerimento permette di ridurre il numero di interazioni necessarie.
E una volta costruita la frase, entra in gioco l’ultimo passaggio:
Text-to-Speech.
Il testo diventa audio.
La sequenza completa diventa quindi:
sguardo → selezione → parola → frase → voce
Costruire velocemente senza rinunciare a capire
C’era però un’altra caratteristica particolare di questo progetto.
Il tempo.
Non stavo costruendo un prodotto seguendo una roadmap di mesi.
Avevo bisogno di capire molto rapidamente se l’idea fosse tecnicamente percorribile.
Ed è qui che l’AI ha avuto un ruolo importante.
Ho utilizzato strumenti di coding assistito per accelerare attività che normalmente avrebbero richiesto molto più tempo:
- esplorare approcci;
- produrre rapidamente prototipi;
- modificare l’interfaccia;
- integrare componenti;
- analizzare errori;
- iterare sulle soluzioni.
Ma velocità non significava delegare completamente il problema.
Ogni proposta doveva comunque essere compresa.
Ogni integrazione verificata.
Ogni comportamento osservato sul dispositivo reale.
Perché quando l’AI rende molto economico produrre codice, il collo di bottiglia si sposta.
Non è più soltanto:
“quanto velocemente riesco a implementare?”
Diventa:
“quanto velocemente riesco a capire se quello che ho implementato risolve davvero il problema?”
Dal codice al dispositivo reale
A un certo punto il progetto ha smesso di essere soltanto codice.
La build Android funzionava.
L’APK poteva essere installato sul tablet.
La fotocamera rilevava il volto.
La calibrazione produceva una mappatura utilizzabile.
Il cursore seguiva lo sguardo.
La selezione permetteva di comporre il testo.
Il Text-to-Speech poteva trasformarlo in voce.
Non era un prodotto medicale.
Non era un sistema AAC professionale.
Non pretendeva di sostituire tecnologie assistive validate o dispositivi specializzati.
Era un prototipo funzionante, costruito per verificare se una determinata idea potesse diventare concretamente utilizzabile.
Questa distinzione per me è importante.
Un prototipo non deve fingere di essere qualcosa che non è.
Deve dimostrare qualcosa.
Quando il requisito cambia
Poi è successa una cosa che, in qualsiasi progetto normale, potremmo descrivere come un cambiamento radicale del requisito.
La necessità per cui VoceSguardo era nato è venuta meno.
E improvvisamente quel software non serviva più.
Potrei raccontarlo come un progetto interrotto.
Ma non sarebbe la lettura corretta.
Perché in questo caso il risultato migliore possibile era proprio non averne più bisogno.
Perché allora pubblicarlo?
A quel punto avrei potuto semplicemente chiudere il repository.
Il progetto aveva svolto la sua funzione.
Avevo imparato molto.
L’esigenza originaria non c’era più.
Ma il problema che avevo cercato di affrontare non era certo unico.
Da qualche parte potrebbe esserci una persona che sta cercando qualcosa di simile.
Oppure uno sviluppatore che vuole partire da questo esperimento per costruire qualcosa di migliore.
Per questo ho scelto di lasciare VoceSguardo disponibile pubblicamente e open source.
Non come soluzione definitiva.
Non come prodotto pronto.
Ma come punto di partenza.
Il codice sorgente è disponibile su GitHub:
VoceSguardo — repository GitHub
Chi vuole può esplorarlo, studiarlo, modificarlo o usarlo come base per continuare a sperimentare.
Quello che mi ha lasciato VoceSguardo
Da questa esperienza mi sono rimaste alcune convinzioni.
La prima è che il problema viene prima della tecnologia.
La seconda è che un’interfaccia non è soltanto qualcosa che deve essere bella o intuitiva: deve essere progettata intorno alle capacità reali della persona che dovrà utilizzarla.
La terza è che l’AI può comprimere enormemente il tempo necessario per passare da un’idea a un prototipo.
Ma proprio per questo aumenta l’importanza del giudizio umano.
Capire cosa costruire.
Capire cosa verificare.
Capire quando una soluzione non funziona.
E anche capire quando non serve più.
Infine, mi ha ricordato una cosa molto più semplice.
Ci sono progetti che nascono perché intravediamo un mercato.
Altri perché vogliamo imparare qualcosa.
Altri ancora perché abbiamo un problema davanti e proviamo, con quello che sappiamo fare, a essere utili.
VoceSguardo appartiene a quest’ultima categoria.
Alla fine non mi è servito.
Ed è andata bene così.
Ve lo lascio qui, insieme a un abbraccio.
Se può esservi utile, il codice è qui: VoceSguardo su GitHub.
Nel caso in cui ne aveste bisogno.
Pubblicato originariamente su LinkedIn il 3 settembre 2026. Questa edizione fa parte degli Insights di Lead From Tech.