5 errori di UX/UI che hanno contribuito a disastri reali
Dalle centrali nucleari ai software medici: cinque storie vere che dimostrano quanto può costare un'interfaccia progettata male.
- Pubblicato il
- 23 ott 2026
- Tempo di Lettura
- 7 min
- Scritto da
- Flaviano Arbia
Una spia che conferma qualcosa che non è successo. Un software che restituisce risultati sbagliati senza segnalarlo. Un'interfaccia che permette un'azione pericolosa senza avvertire chi la sta utilizzando.
Sembrano piccoli difetti di progettazione. Eppure, in determinate circostanze, errori di questo tipo hanno contribuito a provocare incidenti con conseguenze drammatiche.
Quando pensiamo alla User Experience, la associamo spesso alla facilità con cui utilizziamo un'app o navighiamo un sito web.
Ma la UX riguarda qualcosa di più importante: il modo in cui le persone comprendono un sistema, interpretano le informazioni e prendono decisioni.
Nel libro Vita 3.0, il fisico Max Tegmark racconta alcuni incidenti che mostrano quanto sia delicata l'interazione tra esseri umani e tecnologia.
Siamo partiti da quegli episodi, approfondendoli attraverso le indagini disponibili e aggiungendo altri casi documentati.
1. Three Mile Island (1979): la spia che mostrava il comando, non la realtà
Il 28 marzo 1979, nella centrale nucleare di Three Mile Island, in Pennsylvania, una valvola di sicurezza rimase bloccata in posizione aperta durante un malfunzionamento del sistema di raffreddamento.
Gli operatori, però, erano convinti che si fosse chiusa.
Il motivo? Un indicatore nella sala di controllo suggeriva che la valvola fosse chiusa. In realtà, mostrava soltanto che il sistema aveva inviato il comando di chiusura.
La differenza era fondamentale.
Gli operatori interpretarono erroneamente la situazione e presero decisioni che contribuirono al peggioramento dell'incidente, culminato nella fusione parziale del nocciolo del reattore.
Un comando inviato non equivale a uno stato verificato. Illustrazione concettuale, non ricostruzione storica.
L'errore UX
L'interfaccia non distingueva chiaramente due informazioni diverse: ciò che il sistema aveva richiesto e ciò che era realmente accaduto.
Immagina un gestionale che segnala pagamento completato quando ha soltanto inviato la richiesta alla banca.
La lezione: un'interfaccia deve distinguere tra azione richiesta, operazione in corso e risultato effettivamente verificato.
2. Therac-25 (1985–1987): quando un messaggio di errore non spiega il pericolo
Negli anni Ottanta, il Therac-25 era una macchina utilizzata per trattamenti oncologici attraverso la radioterapia.
Tra il 1985 e il 1987, sei incidenti documentati provocarono gravi sovraesposizioni alle radiazioni. Alcuni pazienti morirono, altri subirono lesioni permanenti.
Le indagini individuarono difetti software e problemi nei sistemi di sicurezza. Ma emerse anche un aspetto significativo: l'interfaccia non comunicava adeguatamente la gravità delle anomalie.
Gli operatori potevano ricevere messaggi come Malfunction 54, senza una spiegazione comprensibile del rischio.
Inoltre, la macchina generava frequentemente segnalazioni non pericolose. Gli operatori si erano quindi abituati a riprendere il trattamento dopo alcuni avvisi.
Un codice generico non comunica la gravità di un problema. Illustrazione concettuale, non ricostruzione storica.
L'errore UX
I messaggi non aiutavano a distinguere un problema ordinario da una condizione potenzialmente letale.
La cattiva UX non fu l'unica causa: difetti software e protezioni insufficienti furono determinanti. Ma l'interfaccia contribuiva a rendere più difficile riconoscere il pericolo.
La lezione: un messaggio di errore deve spiegare cosa sta succedendo, quanto è grave e quale comportamento è sicuro. Nei sistemi critici, deve inoltre essere supportato da protezioni tecniche indipendenti.
3. Panama (2000–2001): il software mostrava risultati plausibili, ma sbagliati
Tra il 2000 e il 2001, presso il National Oncology Institute di Panama, 28 pazienti ricevettero dosi eccessive di radiazioni durante trattamenti oncologici.
Il problema nasceva nel software utilizzato per pianificare le terapie.
Il programma prevedeva un limite al numero di blocchi di schermatura inseribili singolarmente. Gli operatori avevano trovato una procedura alternativa per aggirare questa limitazione.
Il software accettava alcune configurazioni, ma calcolava tempi di trattamento errati.
La parte più insidiosa?
La rappresentazione grafica del trattamento appariva corretta.
Il software restituiva risultati pericolosamente sbagliati, presentandoli attraverso un'interfaccia apparentemente affidabile.
Secondo il rapporto dell'Agenzia internazionale per l'energia atomica, al momento dell'indagine del 2001 cinque decessi erano probabilmente attribuibili alla sovraesposizione.
Un risultato visivamente plausibile può nascondere un errore di calcolo. Illustrazione concettuale, non ricostruzione storica.
L'errore UX
Il sistema accettava input che non gestiva correttamente, senza bloccare l'operazione o rendere evidenti i risultati anomali. Anche la mancanza di controlli indipendenti contribuì all'incidente.
La lezione: un software deve aiutare a prevenire l'inserimento di configurazioni incompatibili con i suoi vincoli.
Un risultato visivamente ordinato non è necessariamente un risultato corretto.
4. USS John S. McCain (2017): quando il touchscreen complica un comando
Il 21 agosto 2017, il cacciatorpediniere americano USS John S. McCain entrò in collisione con una petroliera nello Stretto di Singapore.
Morirono dieci marinai e altri 48 rimasero feriti.
L'incidente avvenne dopo una serie di operazioni per trasferire il controllo dello sterzo e della propulsione tra diverse postazioni.
Durante il trasferimento, alcuni comandi passarono a una postazione differente da quella prevista.
L'equipaggio credette di aver perso il controllo della nave, quando in realtà il sistema era configurato in modo diverso da quanto gli operatori avessero compreso.
Il trasferimento dei comandi fra postazioni deve essere chiaramente riconoscibile. Illustrazione concettuale, non ricostruzione storica.
L'errore UX
Le indagini individuarono problemi di formazione, supervisione e procedure operative, ma anche criticità nella progettazione dei controlli.
I touchscreen non fornivano lo stesso feedback tattile dei comandi meccanici e la distribuzione delle funzioni tra le postazioni poteva risultare poco intuitiva.
La lezione: rendere digitale un'interfaccia non significa necessariamente migliorarla.
Un controllo deve essere progettato in base al contesto di utilizzo, non soltanto alla tecnologia disponibile.
5. Hawaii (2018): il menu che contribuì a scatenare un falso allarme missilistico
Il 13 gennaio 2018, gli abitanti delle Hawaii ricevettero un messaggio di emergenza sui propri telefoni.
L'avviso annunciava un imminente attacco missilistico e invitava la popolazione a cercare immediatamente riparo.
Non era in corso alcun attacco.
Si trattava di un falso allarme, ma servirono 38 minuti prima che arrivasse una rettifica ufficiale attraverso il sistema di allerta.
L'errore avvenne durante un'esercitazione interna. Un operatore interpretò la simulazione come una minaccia reale e inviò l'allarme.
Il sistema permetteva di selezionare attraverso un menu i messaggi di prova e quelli destinati alla popolazione.
Prima dell'invio appariva una conferma generica, senza ripresentare il contenuto esatto del messaggio.
Un'allerta pubblica richiede verifiche più robuste di una conferma generica. Illustrazione concettuale, non ricostruzione storica.
L'errore UX
L'interfaccia e le procedure non prevedevano protezioni adeguate per impedire che un errore individuale diventasse un allarme pubblico.
L'indagine della Federal Communications Commission evidenziò anche problemi organizzativi e di supervisione.
La lezione: più un'azione è rischiosa o difficile da annullare, più devono essere robusti i controlli prima della sua esecuzione.
Un semplice pulsante Conferma non è sempre sufficiente.
Cosa hanno in comune questi incidenti?
Cinque contesti diversi, ma problemi ricorrenti:
- Informazioni ambigue: il sistema comunica uno stato che può essere interpretato erroneamente.
- Feedback insufficiente: l'utente non comprende cosa sta realmente accadendo.
- Prevenzione degli errori debole: il software permette operazioni rischiose senza controlli adeguati.
- Interfacce poco adatte al contesto: il comportamento del sistema non corrisponde alle necessità di chi lo utilizza.
Questi episodi non dimostrano che la UX sia stata l'unica responsabile dei disastri.
Dimostrano, però, che la progettazione dell'interazione tra persone e tecnologia può contribuire alla sicurezza o diventare un ulteriore fattore di rischio.
Non serve un disastro per capire quanto costa una cattiva UX
Fortunatamente, la maggior parte dei software aziendali non controlla reattori nucleari o sistemi di emergenza.
Ma gli stessi difetti possono comparire negli strumenti che utilizziamo ogni giorno.
Un gestionale che conferma un'operazione mai completata. Una dashboard che nasconde un'informazione importante. Un sistema che permette di cancellare dati senza possibilità di recupero.
Le conseguenze possono essere meno drammatiche, ma comunque costose: ordini sbagliati, pagamenti duplicati, ore di lavoro perse, clienti insoddisfatti.
Spesso la risposta delle aziende è aggiungere procedure, verifiche manuali e formazione.
Quando, invece, potrebbe essere necessario riprogettare il software.
Una buona UX non elimina necessariamente la complessità. La rende comprensibile, gestibile e controllabile.
Questo è anche il principio che guida il nostro lavoro in Mokap Studio.
Attraverso UX/UI Design e Product Design, aiutiamo le aziende a progettare e migliorare software partendo dalle persone e dai processi reali.
Perché un software può funzionare correttamente dal punto di vista tecnico e continuare a essere difficile da usare.
E perché la chiarezza non è un dettaglio estetico. È una funzionalità.
Hai un software che genera errori, rallenta il team o rende inutilmente complicato il lavoro?
Parliamone. Partiamo dal problema e capiamo insieme cosa può funzionare meglio.
Fonti e bibliografia
L'articolo prende spunto da alcuni episodi raccontati da Max Tegmark in Vita 3.0, approfonditi attraverso studi e rapporti ufficiali.
- Max Tegmark — Vita 3.0. Essere umani nell'era dell'intelligenza artificiale, Raffaello Cortina Editore, 2018.
- U.S. Nuclear Regulatory Commission — Backgrounder on the Three Mile Island Accident.
- Nancy G. Leveson e Clark S. Turner — An Investigation of the Therac-25 Accidents, IEEE Computer, 1993.
- International Atomic Energy Agency — Radiological Emergency in Panama, 2001.
- National Transportation Safety Board — Collision between USS John S. McCain and Alnic MC.
- Federal Communications Commission — Report and Recommendations on the Hawaii False Alert, 2018.
