Center

Il Progetto

Una suite di Web App (PWA) progettata per operare come widget flottanti sui monitor touch industriali della linea di produzione. Nata tra un turno di notte e l'altro per risolvere colli di bottiglia operativi, ha raggiunto un'adozione organica del 100% eliminando l'errore umano nei calcoli dei consumi e nella gestione FIFO.

Codice Sorgente

Il codice sorgente è stato consegnato all'azienda per uso esclusivo. Di seguito documento i momenti chiave del percorso di sviluppo, le scelte tecniche più significative e, soprattutto, gli errori commessi.

Genesi: L'Ossessione

Center rappresenta la chiusura del mio capitolo in fabbrica.
Ho aspettato l'ultimo giorno di lavoro per scriverne, perché solo allora ho avuto la lucidità per raccontarlo senza l'adrenalina della produzione in corso.

L’avevo accennato nel readme UX Engineer Log dove dissi: 

Prima ancora di definirmi UX Engineer, lo sono diventato per necessità in una fabbrica alimentare. Mentre i software gestionali ufficiali venivano ignorati perché complessi e distanti dalla realtà, io vedevo i miei colleghi stressati. Dopo appena 4 giorni nel reparto, ho capito che la pianificazione della produzione giornaliera era il collo di bottiglia. Da lì è nata l'idea di sviluppare una Web App per gestire i consumi orari e prevedere le quantità da produrre. Ne ero ossessionato. Ci lavoravo durante le pause, in bagno, nei turni di notte, tra una serie e l'altra in palestra, arrivando a raffreddarmi i muscoli perché la mente era persa nel creare lo strumento che avrebbero usato tutti. Così è stato. L'app ha raggiunto un'adozione organica del 100%, utilizzata da tutto il reparto su tutti e 3 i turni. Non perché fosse graficamente perfetta, ma perché risolveva un problema reale. Lì ho capito che l'empatia è la skill tecnica più potente che esista. Ben presto, colleghi di altri reparti hanno iniziato a chiedermi soluzioni simili. È stato in quel momento che ho fatto UX senza conoscere la UX: facevo usability test e interviste agli utenti senza conoscere il metodo formale, ma applicandone l'essenza.

In un anno e mezzo di iterazioni, quando ancora non avevo nessuna skill formale di UX e coding, sono riuscito nel mio piccolo ad agevolare il lavoro di due reparti critici all’interno dell’azienda.

Rompere i Silos: La Trasparenza Radicale

In contesti aziendali complessi, ho spesso osservato quella che definirei, per restare in tema, "dinamica dei silos": una frammentazione dove i reparti non si parlano e la conoscenza viene custodita gelosamente anziché condivisa. Ho vissuto situazioni in cui l'innovazione veniva percepita più come un rischio che come un'opportunità.

Di fronte a questo, ho scelto la strada opposta: la trasparenza radicale. Non mi sono limitato a creare software; ho documentato ogni processo, ho comunicato con gli stakeholder e ho condiviso i tool con chiunque ne avesse bisogno. Credevo fermamente che per rompere i silos servisse costruire ponti. Oltre all'applicazione di questo principio nelle Web App, trovavo estremamente efficiente documentare le procedure sotto la supervisione delle figure che avevano risolto i problemi negli impianti. Scrivevo sempre di chiamare comunque le figure di riferimento (come meccanici e controllo qualità) perché uniche autorizzate, ma quei singoli fogli tornavano utili non solo a noi, ma anche alle figure stesse, che spesso non conoscevano accuratamente l'impianto specifico a causa dell'alto turnover.

Mi rendevo conto di come i problemi fossero ricorrenti; ecco perché trovavo inefficiente non avere una guida su come erano stati risolti. Era lo stesso proposito che applicai in Maintenance, uno dei progetti svolti nel corso di Google UX. Alcune di queste procedure sono state poi ufficializzate dall'ufficio senza che io ne facessi richiesta: plastificate, appese alle pareti, copia-incolla delle mie parole. Fu la prima volta che vidi una mia idea "istituzionalizzata" senza passare per burocrazia o approvazioni formali. La trasparenza radicale aveva vinto.

Center-01: L'Evoluzione dei Modelli Mentali

Ecco la primissima versione:

Versione 0.0.1

Un'interfaccia terribile. Eppure, che senso avevano quei due bottoni "Aggiungi 1000 kg"? Replicavano l'esatta procedura che facevamo a mano con la calcolatrice: aggiungevamo 1000 per vedere fino a che ora si arrivava cucinando quella quantità.

Era troppo costrittivo: e se avessi voluto provare con altri tagli di kg per capire quanto cucinare in chiusura e non sprecare materia prima? Ogni fase dell'applicazione riflette le mie conoscenze nella mansione stessa. La risposta arrivò con la seconda versione, con finalmente una cosa "umana" nell’interfaccia: il tempo rimanente in ore e minuti (e fortunatamente anche il CSS).

Aggiunsi un taglio da 500 kg, ma non era ancora abbastanza.
Da qui applicherò un filtro monocromatico, perché anche senza i codici esadecimali esatti, i colori aziendali sarebbero immediatamente riconoscibili.

Ogni modifica la facevo su un IDE chiamato "Koder" su un iPhone 12 mini:

Koder Code Editor

Dove ho finalmente centrato quei box input all’interno del container:

Questo è stato il momento in cui il tool è diventato per la prima volta scalabile. L’operatore aveva la libertà di aggiungere i kg desiderati, esattamente come avrebbe fatto a tentoni con la calcolatrice (la procedura a cui era abituato).

Forse avrai pensato: Perché non chiedere direttamente all’operatore fino a che ora vuole arrivare e calcolare a ritroso la quantità da cucinare? Per due ragioni fondamentali legate ai modelli mentali che avevamo:

1. Eravamo abituati a ragionare per tentativi (aggiungere, togliere, decidere se abbondare in base all'andamento della linea).
2. Non volevo che un'app desse ordini ("Cucina tot kg"). Volevo che l'utente sentisse di partecipare al calcolo.

L'A/B Test Inconsapevole
Nonostante ciò sperimentai ugualmente. Creai una "modalità automatica" che calcolava tutto da sola. Senza saperlo stavo conducendo un A/B test. Il risultato fu netto: la modalità manuale era l'unica utilizzata. Quello che vedi è il tentativo iniziale. Nonostante avessi poi uniformato la grafica a quella manuale, l'adozione rimase nulla: gli operatori volevano il controllo, non l'automazione cieca.

L'applicazione ora aiutava a calcolare con precisione, ma restava un dubbio: e se il consumo orario teorico che ci era stato fornito fosse sbagliato?

Per verificarlo, i colleghi effettuavano le cosiddette "dosate". La procedura era paradossale: si interrompeva il flusso della linea, si faceva colare il prodotto dai dosatori in una vaschetta, lo si pesava per calcolare il flusso, si facevano altri 3 calcoli per ogni singolo dosatore (non pochi) e infine... si buttava via tutto.

Che senso aveva? Analizzando il processo, si generavano 3 sprechi in un colpo solo:

1. Tempo: La produzione non andava a regime.

2. Materia Prima: Il prodotto usato per il test finiva nel bidone (non recuperabile).

3. Processo: Richiedeva l'intervento manuale di un operatore esterno.

Con Center, avevo eliminato tutto questo. Bastava inserire 3 semplici dati: Quantità nei Silos, Minuti trascorsi e Quantità residua. Dopo alcuni confronti, constatammo che il risultato matematico era identico a quello fisico delle "dosate", ma con zero sprechi e zero fermi linea.

Un'altra cosa che scoprii col tempo era che gli orari dei cambi produzione non erano sempre tassativi; a volte l'orario di fine dovevamo calcolarlo in base alla quantità di cartoni ancora da produrre. Era un dato che poteva compromettere i calcoli se non gestito, producendo ingenti avanzi, esattamente ciò che l'applicazione mirava ad azzerare. Automatizzai anche questo calcolo (che fino ad allora si faceva a mano), democratizzando un'operazione che prima era appannaggio solo di chi era più ferrato in matematica e conosceva la formula.

↓

A questo punto lo strumento si è esteso e ha ricevuto l’adozione, seppur non totale, anche in un altro reparto, perché risolveva anche un loro problema, non solo il nostro.

L'Errore della Deduzione (e il perché l'IT deve scendere in reparto)

Ad ogni cambiamento nel reparto aggiornavo l’interfaccia. Quando ci dissero che avremmo dovuto gestire due linee e non più soltanto una, implementai due sezioni identiche affiancate.

Ho fatto l’errore classico che farebbe un Software Engineer che lavora in ufficio e deduce senza vedere con i propri occhi la situazione. In quel momento mi trovavo in vacanza e mi era solamente arrivata voce della nuova linea. Ciò di cui mi resi conto una volta tornato, era che le linee non erano indipendenti come avevo ipotizzato. Una materia prima, in particolare, veniva utilizzata per entrambe le linee finendo negli stessi silos: era un calcolo impossibile da separare a monte, dato che i silos erano condivisi e la pompa smistava il prodotto. La cosa logica (che facevano giustamente tutti) era sommare il consumo orario di entrambe le linee.

Corressi il tiro non appena rientrato, ridisegnando completamente l'interfaccia con un tool chiamato "Krisspy" (non sapevo ancora usare Figma). Volevo tutto in un'unica schermata, con un toggle per "riciclare" i valori già inseriti e finalmente rendere più fluido l'uso della modalità automatica, con anche la possibilità di pianificare due produzioni specificando anche il tempo richiesto per il cambio. Scelsi il seguente mockup:

Ho oscurato, così come nelle altre immagini, i numeri e le diciture specifiche per garantire la massima integrità della proprietà intellettuale aziendale.
Ecco come divenne in fase implementazione:

Center-02: L'Apprendista e il Gatekeeping

La voce si era diffusa al punto che altri 3 reparti mi chiesero una soluzione che potesse essere d'aiuto anche per loro. Ne accettai soltanto una, poiché le altre avrebbero violato le policy sulla proprietà intellettuale o sulla sicurezza dei dati; ho quindi preferito rifiutare spiegandone i rischi. La richiesta che accettai presupponeva il lavorare con un operatore Senior (oltre 30 anni di esperienza nella mansione). Applicai, senza saperlo, il principio dell'Indagine Contestuale (Contextual Inquiry) descritto in About Face: mi sono posto come apprendista, trattando l'utente come maestro nel suo contesto reale.

Il problema tecnico qui era l'algoritmo FIFO (First In, First Out): capire quale lotto togliere per primo in base alla scadenza.

Un dato interessante emerse durante l'adozione: il collega non voleva condividere lo strumento con gli altri. Voleva custodirlo gelosamente. Sebbene eticamente non concordassi, lo presi come la validazione empirica più forte possibile: il software gli dava un vantaggio competitivo tale da volerlo tenere per sé. Fu un déjà-vu, perché la stessa gelosia l'avevo vista nel mio turno. Quando scoprirono che avevo condiviso il tool con gli altri due turni, la presero male: mi chiesero di cambiare la password per tagliare fuori gli altri e tenercelo tutto per noi. Avevo creato ancora una volta, senza rendermene conto, un superpotere.

Norman vs Realtà: Il Fallimento del Timer

Aggiunsi una guida in-app. So che Norman (in "The Design of Everyday Things") e Krug (in "Don't Make Me Think") dicono che se serve un manuale hai fallito. Tuttavia, resto dell'idea che una guida di un minuto sia un prezzo accettabile per evitare errori critici in produzione.

Ma feci un errore. Implementai un Timer automatico di pulizia dati dopo 5 minuti, visualizzato da una barra di progresso. Un'idea "molto da designer", scenografica. Si rivelò disastrosa. Il senior mi spiegò che capitava spesso che non si segnassero al volo i dati di output; procedetti eliminandola. Fu in quel momento che capii che l'eleganza teorica spesso vale zero rispetto al pragmatismo operativo.

Cosa Ho Imparato

Prima di dare le dimissioni ho riaperto il codice sorgente, facendo un refactoring totale per lasciare all'IT un prodotto professionale.

Refactoring e Architettura:

• Trasformazione da "Spaghetti Code" a un'architettura Object-Oriented basata su Classi JS.
• Logica modulare per facilitare la manutenzione IT: per aggiungere una nuova linea basta inserire un oggetto nell'array LINES_CONFIG (id, label, type) e il sistema adatta i calcoli automaticamente.
• Implementazione di percorsi relativi (./) per permettere il deploy in qualsiasi sottocartella della Intranet aziendale senza configurare il routing.

UX e Interazione:

• Responsive Design: Su mobile utilizza un pattern a carosello per massimizzare lo spazio e il focus sui monitor touch; su desktop (o tablet landscape) si "srotola" in una dashboard completa, mostrando tutte le informazioni in un'unica schermata.

• Feedback Visivo: Introdotto bordi colorati sui campi obbligatori (Quantità/Consumo) che si spengono appena compilati, sostituendo le vecchie Call to Action testuali.

→

• Disruptive Actions: Il pulsante "Preleva" ora si disabilita dopo il click per evitare doppi calcoli. L'unico modo per resettare è "Ripulisci Tutto", un'azione distruttiva ma consapevole.

• Distinzione Cromatica: In Center-02, aggiunta distinzione chiara tra la materia prima 1 e 2, su desktop il colore è visibile già all'hover, permettendo di associare la materia prima al relativo Silos ancor prima del click.

Sicurezza e PWA:

• Sanitizzazione totale degli input per prevenire attacchi XSS.
• Navigazione da tastiera completa e adeguamento standard WCAG.
• Eliminazione di tutte le dipendenze esterne: solo HTML, CSS e Vanilla JS.

Strategia Offline-First:

• LocalStorage Selettivo: Center-01 adotta una logica ibrida. I calcoli di produzione sono "usa e getta" (dato che vengono rifatti i calcoli ogni ora/ora e mezza durante la giornata lavorativa), ma le configurazioni personalizzate, come le tipologie di prodotto create dagli utenti, devono rimanere salvate.

• Center-02 invece è totalmente persistente per garantire la continuità dello storico dei lotti.

• Edge Case: Se l'utente preme "Reset completo" mentre è offline (comune nella Intranet), la UI non si rompe e gestisce il ripopolamento della cache al ritorno della connessione.

Riflessione

In poche parole: sono entrato in fabbrica unendo blocchi di codice creando un "Frankenstein" per sopravvivenza. Ne esco lasciando due software scalabili, mantenibili, Mobile e Offline-First.

Ho donato le applicazioni all'azienda, specificando che è l'unica a possederne i diritti. Center non è più mio, ma la lezione su cosa significhi mettere l'utente al centro me la porto via tutta.
Ecco perché ho deciso di chiamarlo Center.