Ridisegnare un'HMI industriale attorno al modo in cui lavorano gli operatori
Un redesign SCADA partito da un mismatch molto concreto: il software organizzava le macchine come entità tecniche, gli operatori le ricordavano per posizione nella linea.
- Ruolo
- UX Designer & Ricercatore Qualitativo
- Team
- Team di design di 2 persone
- Durata
- 4 mesi (Set 2020 - Gen 2021)
- Cliente
- Produttore Europeo di Macchinari Industriali (NDA)
Il progetto in un minuto
La Sfida
Monitoring, reporting, diagnostica e gestione delle ricette convivevano nella stessa interfaccia. Gli stati critici competevano con informazioni di routine e pattern diversi tra prodotti rendevano più difficile passare da una macchina all'altra.
Il mio contributo
- Guida della ricerca UX, con 8 interviste a stakeholder di diversi gruppi utente
- Progettazione e conduzione dell'esercizio Duality Game per far emergere assunzioni implicite
- Valutazione euristica e analisi manuale del sistema esistente
Risultati e portata
Metriche specifiche riservate per NDA
La Sfida
Di cosa mi sono occupato
- Guida della ricerca UX, con 8 interviste a stakeholder di diversi gruppi utente
- Progettazione e conduzione dell'esercizio Duality Game per far emergere assunzioni implicite
- Valutazione euristica e analisi manuale del sistema esistente
- Nuova architettura dell'informazione basata su progressive disclosure
- Progettazione dell'interfaccia delle ricette basata sulla disposizione fisica della linea
- Sviluppo di un design system completo e libreria di componenti
- Creazione di documentazione di riferimento operativo e materiali di formazione
- Consegna di 7 presentazioni sprint che documentano l'evoluzione del design
Monitoring, reporting, diagnostica e gestione delle ricette convivevano nella stessa interfaccia. Gli stati critici competevano con informazioni di routine e pattern diversi tra prodotti rendevano più difficile passare da una macchina all'altra.
Ho lavorato al redesign di un sistema SCADA usato per monitorare e controllare linee industriali di verniciatura e rivestimento. L'interfaccia doveva servire operatori, tecnici di assistenza e ingegneri software, con esigenze molto diverse tra loro.
Dalle interviste è emersa presto una differenza importante: il software presentava le macchine secondo la propria struttura interna, mentre gli operatori ragionavano in termini fisici, per esempio 'il terzo forno che incontro'. Quel disallineamento spiegava diversi problemi nella gestione delle ricette e nella lettura dello stato della linea.
"Un operatore deve capire rapidamente cosa sta succedendo sulla linea; un tecnico deve entrare nel dettaglio; un ingegnere deve poter fare diagnostica anche da remoto. La stessa schermata non può mostrare tutto a tutti nello stesso momento."
Questa distanza tra interfaccia e impianto aumentava il tempo necessario per orientarsi proprio nei momenti in cui serviva capire rapidamente stato, allarme e macchina coinvolta.
Gli operatori osservavano soprattutto la linea fisica e consultavano lo schermo quando qualcosa sembrava anomalo. La gestione delle ricette richiedeva invece di tradurre mentalmente una lista di macchine nella loro posizione reale nello stabilimento.
Ricerca
Interviste agli stakeholder
"Per lo più guardo la linea reale. Do un'occhiata allo schermo quando qualcosa sembra andare storto."
— Operatore di macchina
Gli operatori cercano prima di tutto una risposta operativa
L'interfaccia mostrava velocità, cadenza di produzione, stato delle fotocellule: decine di dati. Che tutto funzionasse gli operatori lo vedevano già guardando la linea; dallo schermo avevano bisogno di capire subito cosa non andava quando c'era un problema.
Le ricette erano difficili da gestire perché l'interfaccia non seguiva la linea
La configurazione delle macchine era difficile da apprendere perché l'interfaccia mostrava una lista ordinata, mentre gli operatori descrivevano la linea spazialmente: 'il terzo forno che incontro camminando'.
Duality Game
Sviluppatori e operatori avevano priorità diverse
Sono emerse differenze tra ciò che gli sviluppatori ritenevano importante e ciò che gli operatori usavano davvero. In un contesto così sotto pressione, le interviste da sole non bastavano a farle emergere.
I comandi fisici e quelli digitali non corrispondevano
Gli operatori resettavano gli allarmi con il pulsante blu fisico, ma l'interfaccia non mostrava chiaramente cosa faceva il pulsante, in che stato si trovava il sistema o cosa sarebbe successo dopo.
Analisi del contesto d'uso
Stabilimenti piccoli e grandi usano il sistema in modo diverso
Negli stabilimenti piccoli gli operatori usavano a fondo tutte le funzioni; in quelli grandi interagivano poco e avevano bisogno soprattutto di chiarezza. Una sola configurazione non andava bene per entrambi.
Gli operatori si orientano sulla disposizione fisica
Gli operatori si orientano sulla disposizione fisica dell'impianto più che su liste di macchine. L'interfaccia doveva seguire il percorso che fanno ogni giorno nello stabilimento.
Insight Chiave
Monitorare e analizzare lo storico sono attività diverse
Il monitoraggio in tempo reale deve far riconoscere subito un problema; il reporting storico serve ad analizzare nel dettaglio. Tenerli nella stessa vista creava confusione.
Gli operatori ricordano le macchine per posizione
Gli operatori ragionano sulla disposizione fisica dello stabilimento: per loro una macchina è 'il terzo forno che incontro', mentre il software la chiamava Machine_ID_3.
Mostrare i dettagli solo quando servono riduce il sovraccarico
Oltre 40 dati visibili contemporaneamente sovraccaricavano la schermata. Con 12 indicatori essenziali e i dettagli in progressive disclosure, lo stato della linea si valuta rapidamente.
La coerenza riduce il tempo necessario per orientarsi
Gli operatori lavorano spesso su più macchine. Interfacce incoerenti allungano la formazione e aumentano la probabilità di errore.
Obiettivi e Principi
Capire subito dove c'è un problema
Gli stati anomali sono stati resi immediatamente visibili, senza richiedere agli operatori di interpretare prima un insieme denso di indicatori.
Seguire il modello spaziale degli operatori
L'interfaccia corrisponde al layout fisico che gli operatori percorrono ogni giorno. La gestione ricette usa una rappresentazione visiva della planimetria.
Informazioni diverse per ruoli diversi
Viste diverse per operatori (focus monitoraggio) vs tecnici (profondità diagnostica) vs ingegneri (configurazione sistema).
Comportamenti coerenti tra macchine e schermate
Un comportamento uniforme su tutta la linea di prodotti riduce la formazione necessaria e la confusione degli operatori.
Principi guida
Prima la chiarezza, poi la completezza
Meglio mostrare meno informazioni ma chiare che mostrare tutto in modo ambiguo, soprattutto quando l'operatore è sotto pressione.
Seguire la disposizione fisica della linea
L'interfaccia segue il modo in cui gli operatori pensano lo spazio fisico, invece delle strutture del database o delle gerarchie tecniche.
Mostrare le informazioni per livelli
Le opzioni avanzate compaiono quando servono, invece di essere tutte visibili fin dall'inizio.
Progettazione della Soluzione
Schema interattivo
Il livello giusto di informazione
Cambia vista per vedere come lo stesso sistema supporta compiti diversi.
Monitorare
L’operatore deve prima localizzare l’eccezione. La panoramica mostra lo stato del sistema senza tutti i dettagli diagnostici.
Stazione 2 → richiede attenzione
Interfaccia concettuale con uno stato di sistema fittizio. Cambia solo la vista; nessun controllo di macchinari o dato di processo live.
Una vista sinottica più leggibile
Troppe informazioni nella schermata di monitoraggio principale: oltre 40 dati visibili contemporaneamente, senza gerarchia visiva, con le informazioni critiche nascoste tra le altre.
Alternative considerate
- Aggiungere controlli di filtraggio per nascondere/mostrare sezioni
- Creare viste di monitoraggio multiple per diversi scenari
- Ridurre agli indicatori essenziali con progressive disclosure
Ho ridotto la vista a 12 indicatori essenziali, con i dettagli in progressive disclosure. Ho aggiunto una codifica colore per gli stati del sistema e ingrandito gli avvisi critici.
Gli operatori non avevano bisogno di una dashboard per confermare che la produzione normale fosse normale: potevano vedere la linea reale. L'interfaccia è stata quindi riprogettata per rendere immediatamente leggibili le condizioni anomale e le azioni richieste.
Compromesso: Alcuni utenti avanzati inizialmente volevano più dati visibili. Risolto con una 'modalità dettagliata' opzionale che manteneva la chiarezza facendo emergere metriche aggiuntive per utenti esperti.
Ricette organizzate secondo la disposizione fisica
La gestione delle ricette era difficile da apprendere perché le liste astratte di macchine non corrispondevano al modello spaziale usato dagli operatori sul campo.
Alternative considerate
- Migliori tutorial e materiali di formazione
- Inserimento parametri semplificato con template
- Planimetria visiva corrispondente al layout fisico
Ho creato una planimetria visiva su cui trascinare gli elementi, con indicatori per le dipendenze e una libreria di template per le configurazioni più comuni.
L'interfaccia ora segue il modello spaziale dell'impianto usato dagli operatori ('il terzo forno che incontro' invece di Machine_ID_3), e le dipendenze tra ricette e macchine sono più facili da capire e da insegnare.
Compromesso: Ogni stabilimento richiede una configurazione personalizzata del layout e il setup iniziale è più complesso. Il netto miglioramento nell'efficienza degli operatori giustificava questo costo.
Far corrispondere comandi fisici e digitali
La relazione poco chiara tra controlli fisici e stati digitali creava un'ambiguità pericolosa nei momenti critici.
Alternative considerate
- Aggiungere documentazione di aiuto a schermo
- Creare materiali di formazione video
- Diagramma visivo che mostra le relazioni pulsante-stato
Ho creato uno schema completo pulsante-stato: un diagramma che mostra i pulsanti fisici, lo stato digitale per ogni posizione, il feedback delle azioni e le procedure di ripristino documentate.
Lo schema è diventato il documento di riferimento tra controlli fisici e interfaccia. Gli operatori potevano capire a colpo d'occhio lo stato del sistema e sapere cosa avrebbe fatto ogni azione sui comandi fisici.
Compromesso: Bisogna documentare tutti i controlli fisici della linea di prodotti e aggiornare lo schema quando cambia l'hardware. Per sicurezza e chiarezza ne valeva la pena.
Risultati e Impatto
Il redesign ha prodotto un prototipo navigabile, un design system condiviso e una documentazione operativa completa. Le scelte principali possono essere ricondotte direttamente ai problemi emersi in ricerca: orientamento sulla linea, gerarchia degli allarmi e separazione tra uso quotidiano e diagnostica.
Metriche specifiche riservate per NDA
Guida di stile e documentazione di oltre 100 pagine consegnata
7 presentazioni sprint che documentano l'evoluzione
Flussi di lavoro quotidiani degli operatori molto più semplici
Carico cognitivo ridotto durante i momenti critici
Riconoscimento e tempo di risposta agli allarmi più rapido
Gestione delle ricette basata sulla disposizione fisica della linea
Mantenuta la profondità diagnostica per i tecnici
Percorsi di troubleshooting più chiari per i team di servizio
Esperienza coerente nell'intera famiglia di prodotti
Una base comune per lo sviluppo successivo
Cosa ho realizzato
- Prototipo Figma navigabile che mostra i flussi di lavoro chiave
- Design system completo e libreria di componenti
- Documentazione della guida di stile (100+ pagine)
- Schede di riferimento operativo per la formazione
- Documentazione della mappatura pulsanti fisico-digitali
- Specifiche dell'interfaccia ricette spaziale
- Sistema di griglia responsive e linee guida per il layout
- Standard di accessibilità e note di implementazione
Riflessioni
Documentazione e handoff fanno parte della soluzione quando il prodotto deve essere mantenuto e configurato da più ruoli tecnici.
Cosa farei diversamente
- Avrei testato prima con gli operatori prototipi a bassa fedeltà, per validare in anticipo i concetti spaziali
- Avrei insistito per avere più tempo di osservazione sul campo, nonostante i vincoli del COVID
- Avrei creato documentazione più completa dei casi limite: il QA ha trovato scenari progettati ma non completamente specificati
Cosa ha funzionato e quali difficoltà ho incontrato
Cosa ha funzionato
Il Duality Game ha fatto emergere disallineamenti
Il Duality Game ha mostrato disallineamenti tra stakeholder che le interviste non avevano fatto emergere. Far discutere insieme sviluppatori e operatori sulle priorità ha reso esplicite differenze importanti.
La progressive disclosure ha reso l'interfaccia più gestibile
Nascondere la complessità finché non serve ha reso l'interfaccia più accessibile senza togliere funzioni. Gli operatori hanno apprezzato un'interfaccia che si apre man mano che cresce la loro esperienza.
Il design system ha reso più coerenti prodotti diversi
I componenti riutilizzabili hanno reso coerente l'intera famiglia di prodotti e accelerato lo sviluppo successivo.
Sfide
Allineare esigenze diverse ha richiesto negoziazione
I diversi gruppi utente avevano esigenze in conflitto: gli ingegneri volevano dettaglio tecnico, gli operatori semplicità, i tecnici di servizio entrambe le cose. Sono servite una negoziazione attenta e una documentazione chiara dei trade-off.
I vincoli tecnici hanno inciso sulle scelte di design
I limiti del sistema legacy hanno costretto a rivedere alcune scelte di design. Ho dovuto bilanciare la soluzione ideale con la fattibilità tecnica e i costi di implementazione.
Lavorare da remoto durante il COVID-19
Per la pandemia ricerca e design si sono svolti da remoto, e ho adattato i metodi di conseguenza. Il progetto avrebbe avuto bisogno di più osservazione sul campo.
Prossimo progetto
Design system PIM per una maison del lusso