Il problema
La rete ferroviaria spagnola conta circa 15.000 km di binari e genera ogni anno milioni di treni-chilometro di dati vibrazionali e acustici. I treni di auscultazione — i veicoli che misurano lo stato delle rotaie — sono tra gli strumenti più sofisticati del kit di manutenzione. I dati che raccolgono sono dettagliati, strutturati e, in teoria, utilizzabili.
In pratica, arrivano come PDF.
Dal sensore al tecnico di manutenzione, la catena è questa: i dati vengono raccolti, elaborati centralmente, formattati in un report, distribuiti via e-mail e interpretati dal tecnico che deve decidere — spesso nella stessa riunione in cui si stanno prioritizzando una dozzina di altre cose — dove mandare una squadra questa settimana. Quando un difetto di usura ondulatoria raggiunge qualcuno con l’autorità per intervenire, sono passati giorni o settimane da quando era rilevabile nel segnale.
L’incidente di Adamuz del gennaio 2026 ha messo l’infrastruttura di sicurezza ferroviaria spagnola sotto l’esame dell’opinione pubblica nazionale. Tra le lacune che ha reso visibili: la distanza tra ciò che il sistema sa e ciò che arriva alle persone in grado di fare qualcosa. BaseLine è stato costruito per affrontare una parte specifica di quel divario — il problema dell’auscultazione.
Ricerca e validazione
Prima di costruire qualsiasi cosa, ho condotto una validazione strutturata dell’opportunità nello spazio del problema, affrontandola da ricercatore UX con deliberato scetticismo verso le letture "risolvibili con la tecnologia".
I problemi strutturali sono reali: intervalli di periodicità tra i passaggi di auscultazione, basso rapporto segnale/rumore nei dati grezzi, visibilità frammentata tra squadre sul campo e sale di controllo, e una latenza dell’escalation manuale che costringe a un lavoro reattivo anziché preventivo. Non sono aneddoti — sono strutturali al modo in cui funziona l’attuale flusso di ispezione.
L’utente primario dell’MVP è una sola persona: il tecnico di triage della manutenzione. Non i macchinisti, non i regolatori, non i controllori operativi, non i dirigenti. Il tecnico di triage prende già decisioni di prioritizzazione, sente già il peso della rilevazione tardiva e può agire senza modificare l’esercizio ferroviario. Ogni altro gruppo di utenti è stato esplicitamente escluso dalla prima versione.
Problema forte, complessità alta, rischio di adozione significativo. La raccomandazione: non costruire subito una piattaforma completa. Partire da una classe di difetti, un corridoio, un gruppo di utenti. Dimostrare che una rilevazione più precoce cambia i comportamenti prima di espandere qualsiasi cosa.
Alti tassi di falsi positivi provocano un abbandono rapido. Le previsioni a scatola nera vengono ignorate o guardate con sfiducia. Le preoccupazioni dei sindacati su sorveglianza e attribuzione di colpe sono ostacoli reali. Qualsiasi sistema che implichi "difetti non rilevati" crea tensioni di responsabilità con i regolatori. Non sono problemi di UX — sono vincoli politici e organizzativi che dovevano plasmare il design fin dall’inizio.
Il perimetro dell’MVP
La definizione dell’ambito è stata importante quanto qualsiasi decisione di design del progetto. Il perimetro è stato scelto abbastanza stretto da sopravvivere alle politiche organizzative, abbastanza utile da cambiare i comportamenti e abbastanza leggibile da guadagnarsi la fiducia di regolatori e tecnici.
L’usura ondulatoria delle rotaie produce firme acustiche e vibrazionali distinte, si sviluppa gradualmente (lasciando tempo per rilevazione e risposta) ed è già ben conosciuta dai tecnici di manutenzione — il che rende più facile calibrare la fiducia. Le linee ad alta velocità AVE sono state esplicitamente escluse dall’MVP: il rischio politico e di sicurezza è troppo alto per partire da lì.
Un singolo corridoio pendolare ad alto traffico con materiale rotabile misto e problemi di manutenzione storici noti. Il compito principale: "aiutarti a decidere dove guardare per primo questa settimana." Non previsione. Non sostituzione delle ispezioni. Non avvisi in tempo reale. Supporto al triage per la decisione settimanale di prioritizzazione che i tecnici stanno già prendendo.
Cosa l’MVP esplicitamente non fa: Non avvisa i macchinisti in tempo reale. Non attiva automaticamente limitazioni di velocità. Non sostituisce le ispezioni. Non classifica le prestazioni di squadre o macchinisti. Non fornisce previsioni temporali di guasto ("guasto tra X giorni"). Ognuno di questi non-obiettivi è stata una scelta deliberata per ridurre l’attrito all’adozione e il rischio di responsabilità.
Cosa ho progettato
Il prototipo è un’interfaccia di triage web-first costruita in Figma Make — un’applicazione React funzionante, non un mockup. Ha due viste principali.
Lista delle anomalie — la vista di triage
La schermata principale è una tabella ordinabile e filtrabile delle anomalie rilevate nel corridoio. Quattro card KPI in alto danno al tecnico una lettura immediata della situazione: rilevazioni totali, in attesa di revisione, gravità alta e tendenza in peggioramento. Ogni riga mostra i cinque segnali necessari per una decisione di triage senza dover aprire nulla: posizione (punto chilometrico), fascia di gravità, livello di confidenza, direzione della tendenza e stato di corroborazione. I filtri si riducono a gravità, confidenza, tendenza e stato — né più né meno.
Dettaglio dell’anomalia — la vista di decisione
Configurazione — soglie controllate dal tecnico
I tecnici possono regolare le soglie di rilevazione per classe di difetto direttamente nell’interfaccia. Ogni modifica viene registrata. Non è un’impostazione sepolta in un pannello di amministrazione — è un flusso di prima classe, perché la calibrazione fa parte del rapporto di fiducia tra il tecnico e il sistema.
Aprendo il dettaglio si vedono le prove dietro la rilevazione: un grafico del segnale su 52 passaggi con la storia grezza delle vibrazioni e la soglia, una card di spiegazione in linguaggio semplice, lo stato di corroborazione da fonti sensoriali identificate e il contesto tecnico completo (posizione PK, tratta, variazione % dell’ampiezza, passaggi confermativi consecutivi). Il pannello delle azioni a destra è l’unico punto in cui il tecnico interagisce con il sistema: revisionato, ispezionare al prossimo ciclo, programmare manutenzione, falso positivo. Ogni decisione viene registrata con l’identità dell’utente e una marca temporale.
Decisioni di design chiave
Ogni card di anomalia si apre con una spiegazione in linguaggio semplice di cosa è stato rilevato e perché il sistema l’ha segnalato: "Aumento sostenuto dell’ampiezza delle vibrazioni laterali sulla rotaia destra. I valori hanno superato la soglia stabilita in 7 degli ultimi 10 passaggi di misura. Il pattern di evoluzione suggerisce un possibile difetto di usura ondulatoria a passo lungo. Confermato in modo indipendente da sensore a bordo linea e treno di auscultazione." Il tecnico legge le prove prima di vedere l’etichetta di gravità — non il contrario. È un’inversione deliberata di come è progettata la maggior parte dei sistemi di allerta.
Ogni anomalia mostra se è stata confermata da più di una fonte indipendente. Le rilevazioni corroborate sono contrassegnate; quelle da fonte singola no. Questo singolo segnale visivo fa un lavoro importante: calibra la confidenza del tecnico prima che legga qualsiasi altra cosa, riduce il costo cognitivo della prioritizzazione e rende leggibile, anziché nascosta, l’incertezza del sistema stesso. Una rilevazione ad alta gravità non corroborata va indagata — ma in modo diverso da una corroborata.
La vista di dettaglio include una nota persistente: "Le decisioni registrate qui sono associate al tuo utente e alla data. Il sistema non esegue azioni automatiche sull’infrastruttura." Non è un disclaimer. È l’impegno di sicurezza centrale del design. Uno strumento di triage in un dominio safety-critical che compie azioni automatiche — o lascia intendere che potrebbe — verrà guardato con sfiducia, aggirato o bloccato dai regolatori. La persona è sempre chi decide. Il compito del sistema è darle informazioni migliori, più in fretta.
L’MVP è deliberatamente stretto: una classe di difetti, un corridoio, soglie regolabili dai tecnici. Il principio di design alla base è che alti tassi di falsi positivi sono la via più rapida all’abbandono in un flusso safety-critical. Un tecnico che scarta tre avvisi senza agire non controllerà il quarto. In questa fase la precisione conta più del recall. L’espansione a più tipi di difetto, più corridoi e flussi di dati più ricchi arriva solo dopo che il sistema si è guadagnato la fiducia operativa.
Nei sistemi safety-critical il valore non viene da algoritmi sofisticati. Viene dal coordinamento tra persone e dati, dalla spiegabilità, dalla riduzione dell’attrito operativo e da un design orientato all’adozione reale.
Prototipo live
Costruito in Figma Make — un’applicazione React funzionante, non un mockup. Apri la versione a schermo intero per interagire con la lista delle anomalie, entrare in una vista di dettaglio e usare il pannello delle azioni.
Proposta di pilota
BaseLine è progettato per essere validato in un pilota operativo di 90 giorni prima di qualsiasi impegno verso un rollout più ampio. Il pilota è strutturato per produrre una prova binaria: i tecnici agiscono in modo diverso grazie allo strumento, oppure no?
Accesso ai dati esistenti dei treni di auscultazione per un corridoio — nessun nuovo hardware oltre la scala del pilota. Da quattro a sei tecnici di triage della manutenzione che partecipano a sessioni di revisione quindicinali. L’impegno che le raccomandazioni del pilota non generino responsabilità a meno che il tecnico non scelga di agire su di esse.
Segnale di successo primario: il 30% o più delle anomalie revisionate porta a un cambio di priorità di ispezione o manutenzione. Segnali secondari: i tecnici riferiscono di essersi accorti prima di difetti che non avrebbero colto così presto; il tasso di falsi positivi resta entro la tolleranza autodichiarata; zero incidenti operativi causati dalle raccomandazioni del pilota. Segnale di fallimento: lo strumento viene controllato una volta e poi ignorato; gli avvisi vengono scartati senza revisione; i tecnici chiedono invece i PDF.
Seconda classe di difetti (bruciature da slittamento ruota). Corroborazione inviata dai macchinisti (solo a treno fermo, nessuna interazione in movimento). Copertura estesa dei corridoi. Companion mobile in sola lettura. Livello di pianificazione della manutenzione predittiva. Ogni passo è condizionato alla dimostrazione dell’impatto comportamentale del precedente — non alla capacità tecnica di costruirlo.
Il prototipo è completo e documentato. Specifica di integrazione, facilitazione della ricerca UX e progettazione del pilota sono disponibili. Chi è interessato può scrivermi a josue@perex.design o prenotare una call di 30 minuti.
Risultato
Un prototipo funzionante validato rispetto a un framework di ricerca strutturato, con una definizione dell’MVP nettamente circoscritta e una proposta di pilota concreta. BaseLine non è un concept — è uno strumento di supporto alle decisioni che può essere messo davanti ai tecnici di manutenzione e valutato su esiti comportamentali misurabili entro 90 giorni.
La ricerca, il prototipo e il framework del pilota sono disponibili. Il prossimo passo è un operatore partner.
Come è stato realizzato
BaseLine è stato ricercato, specificato e prototipato con l’assistenza dell’IA dall’inizio alla fine, lavorando con Claude sulla ricerca di dominio e con Figma Make sulla build interattiva. Le decisioni di ambito — il singolo utente tecnico di triage, l’esclusione delle linee ad alta velocità AVE — sono state le parti che nessuno strumento ha preso al posto mio.
La direzione di prodotto, i vincoli e ogni decisione di giudizio sono miei. Dichiaro il metodo in modo esplicito perché è così che lavoro oggi — e perché essere vago sulla provenienza indebolirebbe il punto.