
Part Production Cell — MES & OEE
OpenPLC, Ignition Perspective e SQLite: eventi, KPI e cause dei fermi macchina organizzati in modo chiaro.
Trackly è un prodotto iOS compatto, ma il lavoro di design riguardava comunque la disciplina di prodotto: scegliere lo scenario principale, eliminare le distrazioni e rendere leggero l’uso quotidiano.
Ho progettato il flusso delle abitudini, gli stati di avanzamento, l’onboarding, la direzione visiva e l’implementazione SwiftUI, così che l’app potesse passare rapidamente dal concetto all’App Store.
L’obiettivo non era il volume di funzionalità, ma coerenza, feedback chiaro e una struttura a cui gli utenti possano tornare ogni giorno senza sentirsi sovraccarichi.

Sono partito dalla schermata iniziale e dal principale ciclo quotidiano. Il prodotto doveva trasmettere calma, quindi ho mantenuto visibili i progressi senza trasformare l’app in una dashboard. I dettagli delle abitudini restano separati: gli utenti approfondiscono per scelta, non per obbligo.

Voglio vedere le abitudini e segnare rapidamente il completamento, così non devo ricordare tutto a mente.
Voglio aggiungere un’abitudine in pochi secondi: sceglierne una pronta o crearne una mia e iniziare subito.
Voglio vedere giorno, settimana e mese per capire la costanza, senza basarmi solo sulle sensazioni.
Questa volta sono partito dalla logica, dagli stati delle schermate e dagli scenari prima di passare a design e codice. Costruire personalmente l’architettura ha reso l’implementazione più prevedibile e ha aiutato a mantenere le decisioni di design più vicine all’app finale.

Sono partito dai componenti iOS di base. Volevo vedere subito dove le soluzioni standard erano sufficienti e dove serviva una soluzione personalizzata.
Ho costruito schermate realistiche e verificato gli scenari. È diventato chiaro cosa semplificare e dove mancavano accenti visivi.
Ho definito periodi e dati, aggiunto una pagina di dettaglio e marcatori visivi. Lo stato si comprende a colpo d’occhio.
Questa fase è andata senza stress: volevo solo distinguermi. Il feed dell’App Store era molto piatto — colori pastello e la stessa atmosfera. Ho scelto la direzione opposta: più luminosità, colore principale dal blu al rosa. Anche l’icona e l’attenzione a un pubblico femminile hanno avuto il loro ruolo.

Nessun colpo di scena dai riferimenti: ho esaminato con calma le opzioni, da troppo neutre a chiaramente superflue.
Il blu sembrava freddo, il verde troppo legato alla salute. Il rosa dava l’emozione e la memorabilità giuste.
Ho rafforzato gli elementi chiave, eliminato il superfluo, inviato la build a TestFlight e verificato l’uso reale.
Conoscevo già le meccaniche dell’onboarding. Questa volta non ho spiegato l’interfaccia: ho comunicato il valore. Domande, emozione, frasi brevi, animazioni. L’onboarding è diventato parte del prodotto, non un’introduzione.

Il marketer mi ha aiutato a vedere l’onboarding in modo diverso: non come elenco di funzionalità, ma come momento per comunicare valore.
Ho ragionato su dove fosse necessario il video e dove bastassero soluzioni native. Alla fine sono rimasto in Xcode: più affidabile.
Ho realizzato le animazioni con conoscenze Swift di base. Anche senza di esse l’onboarding funziona: testo e struttura lo sostengono.
Conclusioni

OpenPLC, Ignition Perspective e SQLite: eventi, KPI e cause dei fermi macchina organizzati in modo chiaro.

OpenPLC e Ignition: logica Ladder, macchina a stati in Structured Text, feedback dei sensori e cicli normali verificabili.

Monitoraggio enterprise per una centrale nucleare: stati del sistema, vincoli ingegneristici e logica 3D degli stoccaggi.