Salta al contenuto
ProgettiProduct design

Greentech Solution

Dal marchio alle interfacce di controllo dei mezzi, in aria e in acqua. Il progetto in cui ho seguito da solo tutto il percorso: identità, prodotto, dati e front-end.

Cliente
Greentech Solution
Anno
2012–2015
Ruolo
Product design B2B, data visualization, brand identity, front-end
+30%operatività degli utenti tecnici
4software interni portati su una UI sola
aria + acquamezzi coordinati in un unico sistema
LINEA DI COSTAGT-A148 mGT-A252 mGT-M1-14 mGT-M2-9 mAEREO 01 · 4,2 haAEREO 02 · 5,1 haNAVALE 01 · 6,4 haNAVALE 02 · 3,8 ha

Ricostruzione. Non è una schermata del software.

Quattro mezzi si dividono un'area e la battono a strisce: due in aria, due sull'acqua. Dietro ognuno resta la parte già coperta, che è l'unico dato che l'operatore guarda di continuo.

Ricostruzione

Non è una schermata del software.

Due mezzi in aria scansionano il mare, due sull’acqua vanno al recupero: si dividono un’area e la percorrono a strisce. Dietro ognuno resta la parte già battuta, il dato che l’operatore guarda più spesso.

Sotto c’è il principio del sistema: più mezzi, una sola area, una lettura continua di quanto è stato coperto.

Il problema

Greentech Solution fa monitoraggio e controllo per i servizi ambientali e industriali, e nasce soprattutto sul controllo e la bonifica dei mari. I droni non sono il mestiere, sono lo strumento: un drone aereo scansiona il mare con una termocamera e individua plastiche e rifiuti, un natante automatizzato va a recuperarli. Il software che coordina questi mezzi, dentro l’industria 4.0, è quello su cui ho lavorato.

Il codice c’era già e funzionava, nel senso che i calcoli erano giusti. Il resto era un problema di persone. Chi lo usava passava dalle schermate per prendere decisioni operative, spesso in fretta, e ogni volta doveva ricostruirsi da solo il senso di quello che stava guardando.

Fuori, intanto, l’azienda non aveva niente. Nessun marchio, nessun sistema di colori, nessun sito. Chi vende tecnologia industriale parla a clienti che valutano competenza tecnica, e presentarsi senza un’identità non è neutro: è un’informazione anche quella.

Non è il tipo di progetto in cui si parte da una ricerca sugli utenti. Si parte da requisiti ingegneristici scritti da chi conosce la macchina e non ha motivo di tradurli, e il primo lavoro è capirli abbastanza da poterli mettere in discussione.

I vincoli

Un pannello di controllo mission critical ha una regola che l’editoriale non ha: se l’interfaccia rallenta la lettura di un dato, il costo non è l’insoddisfazione, è la decisione sbagliata. Con dei mezzi fuori, in volo o in mare, quel costo ha anche una forma fisica.

Questo taglia fuori una parte grande del repertorio visivo:

  • niente animazioni che facciano aspettare
  • niente gerarchie da imparare
  • niente colore usato per decorare
  • niente informazione importante affidata solo alla forma

Nelle schermate operative, del resto, il colore è già occupato: dice lo stato del sistema.

L’altro vincolo era la coerenza. I software interni erano quattro, cresciuti per sedimentazione, ognuno con la sua idea di tabella, di form, di gerarchia e di allarme. Passare dall’uno all’altro voleva dire cambiare lingua.

Il prodotto

Ho definito da zero la product experience dell’ecosistema digitale:

  • architettura dell’esperienza
  • dashboard B2B di monitoraggio
  • sistema di data visualization
  • pannelli di controllo
  • interfacce per la gestione dei mezzi
  • standardizzazione dei quattro software interni
  • implementazione front-end

L’obiettivo non era rendere tutto uguale, ma portare strumenti diversi dentro le stesse regole, così che passare dall’uno all’altro non chiedesse ogni volta di imparare una grammatica nuova.

La parte che mi ha insegnato di più è stata la data visualization. Un grafico che mostra tutto quello che il sistema sa è più facile da progettare di uno che sceglie. Scegliere vuol dire decidere cosa l’operatore vede per primo, cosa può ignorare e cosa deve capire subito. È una responsabilità che non si risolve dentro Figma: va discussa con chi conosce le macchine, i dati e cosa costa una lettura sbagliata.

Il sito, e i droni che si muovevano

L’ultimo pezzo è stato il sito istituzionale, dall’interfaccia fino all’HTML e al CSS che lo mandano online.

La home non è un’introduzione, è un bivio: riquadri pieni a tutta pagina, Azienda, Sperimentazione, Network. Dentro, fotografia grande e nient’altro. Chi arriva su un sito industriale non arriva per leggere, arriva per capire in pochi secondi se sono l’interlocutore giusto, e un menu a tendina glielo dice peggio di quattro immagini.

Il pubblico lì è commerciale e la domanda è una sola: questa azienda sa fare quello che dice? Una fotografia di un drone fermo non risponde. La cosa che convince è il mezzo mentre lavora, che batte un tratto di mare e recupera quello che trova. Quindi in apertura i droni si muovevano davvero.

Non era un effetto. Era la versione ridotta di quello che il software faceva per intero, messa dove serviva a spiegarlo in tre secondi a chi non lo aveva mai visto.

Il disegno in cima a questa pagina è la ricostruzione di quel movimento. Il sito originale non è più online e le schermate del software sono del cliente: quello che si può rimettere in piedi è il ritmo, non il contenuto.

Il sito su desktop e telefono: i riquadri pieni della home
La home come bivio: quattro riquadri, fotografia grande, nessun menu da leggere.

Cosa mi porto dietro

Due cose. La prima è che quando un utente tecnico deve decidere in tre secondi, l’estetica serve solo se toglie attrito. È una frase che uso ancora oggi sull’editoriale, che è un mestiere lontanissimo da questo, e regge lo stesso.

La seconda è che quando disegni sapendo che poi lo scrivi tu, disegni diverso. Qui il ciclo si è chiuso per intero sulla stessa persona: nessun handoff, nessuna traduzione persa. Sparisce anche la voglia di soluzioni che in Figma sembrano gratis e in produzione costano una settimana.